An interesting opportunity showed up a few weeks ago just after returning from my paternity leave. My brain was still stuck and asleep when my co-workers were presenting me the last “Death or Death” project. They told me we had only 4 months to deliver a new software before the Nothing.
*Thanks to Michael Ende for describing the life of most software developers in this world.
After some workshops that we held to create a common understanding about the problem, we discussed about our critical situation and we decided to promote our agile principles and values even more. We reinforced next ideas:
- Delivering the highest quality software iteratively
- Building and designing it incrementally
- Communicating constantly with customer
- Focusing on customer needs
Thus, the following techniques or tools were planned to be used in our last *cough project:
- #impact mapping
- #Lean Software Development
- #Visual Management + Metrics (CycleTime + CFD + Release Burndown chart)
The intent of this blog isn’t to create a prescriptive recipe for your software development process but to provide insights into the reasons to using any specific technique.
Despite the fact that this tool is designed for strategic planning and very useful for managing projects in the long run. We decided to use this tool for helping the team visualize the product backlog as a report (information radiator) in the short term. This simplification of the diagram seeks to respond to the following questions at first sight:
- What the customer wants in plain text
- How to provide value. In User Story format. As a I want so that
Sometimes It is needed to break down the “how” item into smaller pieces following User Story format in order to give even more detail about the content of the How node or Epic.
This technique which I discovered thanks to the promotion of Woody Zuill consists of one team, one active keyboard and one projector.
As they promote: It’s just like doing full-team pair programming.
There are two roles involved: navigators who discuss, think, design and guide the driver who is in charge of writing the code that navigators are dictating. Every 15 minutes the driver role is rotated.
Team’s feedback after two weeks is terrific. They highlighted the following emergent behaviors:
- Alignment: The whole team took part of the architecture. In fact, all team members coded and designed the emergent architecture.
- The whole team defined a solid foundation for coding standards and code quality rules.
- More meaningful DONE DEFINITION.
- They learnt a lot from each other and specially programmers from senior developers.
- Ups, I hardly forget to mention that: Resharper is cool.
Please, see more information here: http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/
I told to someone some time ago that the book Specification by example from Godjko Adzic had radically changed the way I understood software development. Although, I didn’t have much experience (only 2 projects), it has become an irreplaceable tool for any project that I work in.
As an Agile coach I try to encourage the team to practice BDD and follow next rules:
- Technology changes but domain remains. We avoid testing presentation layer and we make effort to test only our business services. Presentation layer is either delegated to exploratory testing or programmed with an automation tool whether it’s worth investing in it.
- Using Ubiquitous Domain language. Formal language must be shared by all members of the software development team – both software developers and non-technical team members.
- Testing the real system. Continuous Integration machine provides feedback on a daily basis about the health of the system. We are especially interested in performance issues or integration problems with external components. We are promoting to integrate external components as soon as possible or mocking them until a stable version is ready to integrate.
- Embrace BDD refactoring. Re-read and re-write your tests many times in order to minimize misunderstanding or ambiguity and search for inadequate feature or scenario definition. The purpose of the scenario is to describe what the system has to do. Likewise, the feature describes the acceptance test. We use the standard agile framework of a User story for its definition.
- Defining specifications collaboratively: Specification by example mentions several ways to create specifications: formal workshops, informal conversations, 3 amigos. Inspect them and adapt to your context.
As I am writing this blog is I wonder about the possibility to create a specification quality control policy which is a check list for early identification of common issues affected by specifications and help reduce rework.
#New Product Development
Although I got excellent results following the Scrum framework along these years I have been progressively more interested in Lean Software Development, Kanban and New product development and less interested in estimations, the usage of them from middle and upper layers, conflicts provoked by estimations and the relationship with team commitment. Thus, our current software development process is a mix of ideas from different sources and frameworks.
Once every two weeks we release a new version and facilitate a review for our stakeholders. This cadence reduces the team’s coordination cost and creates a sense of urgency to deliver value as soon as possible and receive feedback from stakeholders. Besides, we have also limited work in progress (WIP) in order to provide enough flexibility and adaptability to variability. I took a change to facilitate a Systems thinking analysis meeting to create an awareness of potential effects of modifying the value and how to increase and decrease it. The team has managed this WIP internally so far with responsibility adapting it to the continuous context change.
Although our Done definition includes an statement that states: 0 bugs, some of them have shown up and we decided to create a queue for them. The queue size is very little (only 6 bugs) and team usually reacts very quickly to keep the queue under control. One of the interesting effects of limiting WIP is that developers are capable of dealing with variability (bugs) faster than other teams that I led in the past.
First blog entry described how we are going to use our metrics cycle time and lead time but it only mentioned cumulative flow diagrams. Now it’s time I explained to you in more detail the usage of this metric.
This metric aims at helping track and monitor how user stories are moving through various stages of the process to being “done”.
From a cumulative flow diagram we can see:
- Where the bottlenecks are in our flow. Based on Theory of Constraints introduced by Eli Goldratt we must exploit the bottleneck, optimizing the throughput of the system adding more capacity or changing how the system is performing. Thus, if we apply continuous improvement frameworks like PDCA or Build – > Measure -> Learn we can easily evaluate if our policies are improving the flow.
- If demand is seasonal and take steps to adjust capacity in that case.
- If we are delivering value at the end of the process and how to improve them (global view of the process).
Finally, we use release burndown chart to indicate the progress of the team against the product backlog. The diagram is updated every week.
Picture provided by Wikipedia.