(Note: this posting is written in story format. The situation described did occur.)
‘It cannot be done. We can prove it to you. When is your next visit?’ They sounded almost giddy. My engineering team had been hard at work in their Scrum transformation. They were doing well with shift-left testing, story grooming, spikes, sprints, planning, reviews, retrospectives, and agile architecture. They were solid on implementing small increments of work to known good. Their next hurdle was, to completely implement and release stories within a two-week sprint. After attempting this for a fair number of sprints, they had proof that a story could not be implemented within such a small window of time. I was heading out for my routine visit, so I scheduled the meeting to hear their proof.
A bit of back story on this team. They were a Scrum team who was one of 20 teams who were building a private cloud offering with fully automated virtual and physical provisioning with full ITIL integration and reporting. The 20 teams were dispersed in the US and India. They had deployments in production with hosting providers and end-user customers. The architecture of the product was complex and built initially with 3rd party components. The team was removing the costly 3rd party components and replacing them with their own IP and open source to lower costs and improve integration. They were over 2 years into Scrum adoption and were reaching maturity. The team with the proof had two of the smartest engineers on the project.
As I walked into the conference room, the team was prepared. They knew that that they challenged me before and walked away with more to learn. However, this time they had everything worked out. They started to lay out their case. 2 days to do the architecture review and ensure that the solution the change would pass muster. 3 days for design work and working any dependencies across components. 4 days implementation. 2 days for documentation and 3 days for test and final integration. Add them up, we have 14 days of work. A two-week sprint is at best 9.5 days of work. The work cannot be completed within a sprint. Even if they could reduce a day off each (except of course documentation because that goes to another group), they need 10 days. This still doesn’t fit. They went even further. They tried to break the user-stories into even smaller increments. They showed how they reached the point of diminishing returns where the overhead of architecture checks and validation did not justify the amount of work. They tried to reduce the implementation time. But, they needed time to verify the implementation could be done and adjust the design as they implemented. They had to ensure that everything was consistent before going to documentation. They knew that they had me. They rested their case.
I responded that they were, in fact, correct. Given how they did the work, really a mini-waterfall process, that they could not reduce the time any further. They started to smile. I saw a fist pump in the air from one of the junior team members. However, they could, in fact make the work fit within a two-week sprint if they re-ordered the work, even for the example of the longest time. They stared at me. The fist dropped.
I went to the whiteboard to write. The 2-day architecture review would stand on its own. The 3 days of design work, 3 days of test development, (this is known as test driven development, I prefer test driven design), and 2 days for documentation could, in fact be done in parallel. The final step is doing the implementation exactly to the design, documentation and to pass the tests, all unmodified. This adds up to 2 days plus 3 days plus 4 days or 9 days. It fits within the 9.5 days for the two-week sprint. In their example where they trimmed a day off the steps, this shortens to 6 days, well within a two-week sprint. I termed this style of out-of-ordered work, the T-shaped development model because architecture verification is the left arm of the T, design, documentation and test make up the center of the T and are done in parallel with implementation the right side of the T.
They challenged.
The team learns a lot during implementation. They adjust the design, make improvements and sometimes renegotiate with the PO on the story or user-outcome. Doing the implementation at the end, exactly to the design, documentation and test, means that this cannot be done. I confirmed that the T-shaped development model would prevent this learning iteration during the implementation. I claimed that preventing the iteration is exactly the right thing to do. Scrum values transparency. If the team is doing improvements hidden away from the PO and the business, how do the stakeholders via the PO weigh into the discussion? The T-shaped development model requires that any learning made during implementation goes into the backlog as future improvements or increments. All future changes, improvements or new features in the backlog are prioritized and groomed based upon value. If the ideas uncovered during implementation are valued sufficiently, the PO will move them up against other backlog items. If the ideas uncovered during implementation aren’t of sufficient value, they are never implemented. The team is rightly directed to higher value backlog items. Hence, the team avoids waste of unvalued work/features delivered to customers when using the T-shaped development model.
They challenged more.
They use the implementation to know what can be done. I pointed out that if they shift to Test Driven Design where they implement the tests (that all fail at onset, of course) based upon the design and end user documentation, they can reach a similar understanding of what should be done. Since there is no implementation yet, they can adjust the design, documentation and/or test faster. If necessary, the PO can review the documentation to verify that, when done, it meets the user outcome that she is expecting. The implementation is just done to those exacting expectations. I argued that during implementation, the engineer is 100% focused and knows exactly what is needed. There is no second guessing. The engineer knows exactly what ‘done’ is. The implementation quality will be higher.
They weren’t done challenging.
They cannot engage documentation in such a fashion. The documentation team only works on final increments and in batches from all the Scrum teams. I agreed. Now is the time to change how documentation is done. Historically, documentation owned the content, editing (editor role) and delivery mechanism. Now, documentation content is done by the Scrum team, incrementally. The documentation team takes on the role of enabler of Scrum team developed content to flow through to customers in a consistent and incremental fashion. The Documentation team moves from editor to publisher. They own and set the standard (really an aspect of architecture here) for how content flows in a coherent fashion from Scrum team to customer.
The team paused and thought. They moved to acceptance.
They agreed that T-shaped development model, if done, would enable the team to implement stories within a 2-week sprint. To their credit, they responded that they now understood how work re-ordering could be done and would result in a viable, well-engineered outcome. They did not know how to do it. They agreed that they would take on this approach and figure out how to make it work.
It took the team about six months to master the T-shaped development model. They had to hammer out an agreement with documentation on this new approach. They invested in mastery of TDD tools and methods. After they got the T-shaped development model working, they did achieve stories being done within a two-week sprint. They also discovered that there was leverage in their work one story to the next story. They increased their velocity. They found that they could lower the overhead of architecture, design, TDD, documentation and implementation too because they took out time built in for iterations and improvements. They used the backlog and grooming instead. They no longer held the 14-day, or even 6-day minimum cycle time due to their previously claimed ‘overhead’ dogmas.
No comments:
Post a Comment