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.
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.
This discussion is about respect in attending work related meetings. The undertaken consideration and hints may not work properly for private meetings. There’re taken into account organization’s meetings including plannings, retrospectives, reviews, standups, all hands meetings, presentations. They apply to both onsite and remote venues.
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.
The traditional circles and soup technique is performed usually on retrospectives of not successful sprints. The technique could be used for release and project retrospectives as well. Basing on my observations there are very often small successes even in failed sprints. The circles and soup technique does not respect them. I would like to present here my extension to the circles and soup technique which I use at work. I call it multiverse circles because this one introduces the parallel positive universe in addition to the impediments base.
The aim of this publication is to consider usability of estimation in software development context. We will cover here a matter of estimation rather than exact estimation techniques. The consideration has in mind particularly agile environment. I wrote this post basing on my experience and observations. I have worked in various teams with different approaches to estimation. In some teams estimation techniques were changed along with time.