First of all, this is a very tricky topic. Even though, perfectionism doesn’t contradict incremental development and incremental development doesn’t contradict perfectionism, these terms aren’t best friends for now. Perfectionism tends to focus on details while incremental development addresses optimizing value and taking right direction. Incremental development is supported by agile mindset. Perfectionism in this paper is mitigated to a mindset of a desire to develop perfect solution.
Sometimes you simply want to be clear if something is either true or false; fuzzy states are not acceptable. In this post I’ll try to help you to cope with such cases having agile methods in particular in mind. It’s about defining and crossing the threshold in order to enter into more efficient software development method. Once the goal is defined we need to know how to achieve it and finally measure the achievement when the threshold will has been crossed. We refer to Crossing the Rubicon idiom to address the topic.
I had a pleasure to be speaker and attendee on the Quality Excites Conference. The conference took place last Saturday in Gliwice on the 24th of June, 2017. That’s was a very hot day with a very cool atmosphere during the event. The conference attracted people excited by software quality. We could meet both quality experts and also those attendees who became more aware of software quality after the conference.
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.
We use examples on a daily basis. This publication provides a motivation to giving examples, especially in a visual form with a purpose to clarify certain issue. Explaining through examples bases on comparisons. The visual approach is strongly preferred because of the visual nature. The nature creates an opportunity to instant consumption of the content. Simple picture can provide more information than tons of words. Some visuals require comments, though. We consider here both the positive and the negative power that pictures can bring.
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.