This is a brief summary of the J On The Beach conference. The conference’s organizers say: J On The Beach is an international rendezvous for developers and DevOps around big data technologies. A fun conference to learn and share the latest experiences related to topics like distributed systems, IoT projects, Big Data Architectures and, the most important part, it’s On The Beach!. They delivered what they promised. There was fun and a opportunity to learn something new.
Scrum Teams have a privilege to be cross-functional and self-organizing. These traits are proudly manifested by such teams. However, this becomes more complicated when it comes to implementation. One challenge it to get approval and empowerment from organization to act as a real Scrum Team. The second is Scrum Teams believing and determination in behaving accordingly to their agreements. Teams are build from people with unique talents and different preferences. Ultimately, the team has to be solid and consistent in its activities and results. The internal teams diversity and external consistency gives an opportunity to create innovations, and creates a challenge too.
Together with two colleagues from SAP hybris we’ve elaborated and provided a lecture with labs about Agile for students. We’ve been asked to deliver the lecture and labs covering practical Agile issues for students from the Silesian University of Technology. We advertised our session as: Agile – how it really works? within the Hack Your Career activity.The purpose was to take into consideration Agile area from the practical point of view.
The goal of this article is to put emphasis on introducing Tech Debt identification and evaluation into development process on a daily basis. We notice that not every Tech Debt symptom makes a real debt worth to work on. There’s also addressed how Tech Debt is defined in quality expectations and how it’s correlated with Business Value.
The cooperation with external people may be a challenge for agile teams. These people are often experts working as a smaller or bigger part of an agile team. As long as an expert is not a full-time and dedicated team member involved in development lifecycle, this is a challenge to organize common work in a consistent way. We consider factors making the cooperation inconvenient. There are also produced common working agreements supporting organization of mutual collaboration.
Companies are getting bigger, projects do so, and a need of scaling grows. The purpose of this post is focusing on aspects of building agile scaling scheme in an organization. There are taken into account communication and integration aspects. These aspects are often not properly executed or neglected at all. They are in fact inevitable factors in achieving scaling goal.
I’d like to shortly summarize here the Spring IO 16 Conference. I attended the conference last week together with my colleagues from work. This was my second time on the Spring IO Conference. In general I’d say this edition was quite similar to the previous one.