Agility needs to get onto the next level – that´s what I tried to explain in my previous articles. After a reality check – what´s missing from Agile practice? –, and some general musings about how a next level of Agility could look like, here now some very tangible suggestions.
Crank up the frequency
Current Agile practice is suffering from too little attention to Acceptance. To change this, very, very clear Acceptance dates need to be set. Acceptance can only get into a real pulling mode, if dates are fixed.
However, a date in weeks or months from now has no real pulling force on a team. This is obvious whenever you see a team change its working mode during an iteration because iteration end/delivery date is coming closer.
Acceptance always has to be around the corner. That means Acceptance has to be each and every day. That´s a frequency exerting real pull power over a team.
Yes, I mean it: A team should deliver a value increment every evening.
That´s how fast the development process should rotate at the core, at the implementation level. Delivering every day should be the default, the norm, the ideal. After sprinting comes Spinning.
Every evening (or next morning) the Acceptor should stand in the door of the team room an ask, “What have you got for me today?”
Again: I mean it. Requirements can and should be so finely sliced to be able to deliver value on a daily basis. This is possible, but it might require some training and good will. So please suspend your skepticism; don´t think, “This is impossible!” – but ask yourself “What could the benefits be?” Because there are many benefits to be reaped:
- Benefit #1: The team gets feedback on a daily basis. What got implemented yesterday is checked today by the Acceptor – and immediately returned upon dissatisfaction. All mental state about what the feedback is about is still present in the team.
- Benefit #2: If feedback is immediate and only a small increment has been added, not much waste can have been produced. Daily Acceptance transforms a project from ballistic flight to steered flight.
- Benefit #3: Where Acceptance is daily, the customer can change his mind daily. The team is never caught in limbo. At the end of the day it´s done. So it can take up whatever challenge the customer proposes for the next day. The customer is most flexible in how he wants the software to evolve. Delivering on a daily basis for Acceptance make it perfectly ok for the customer to change his mind on a daily basis.
- Benefit #4: The customer can stop work on features at any time. No features needs to be completed according to spec. This can safe quite some money, if a “good enough” state is reached before 100%. This can be checked for with daily Acceptance.
- Benefit #5: Not only the customer can change his mind daily, also the team can. It can allocate its resources very flexibly every day. That way, even most emergencies need not interrupt the team; they just get postponed a couple of hours until the next “planning point”, which is not father away than tomorrow.
Yesterday´s waterfall software production was like shooting a movie. The script needed to fixed for production planning and shooting.
Today´s agile software production is like shooting a TV series. An overall plot needs to be pretty much fixed before production can start, but the script for each episode can be written later. Each episode is like a sprint, a season is like a milestone release.
Tomorrow´s elastic software production then looks like improvisational theatre. There is just a rough idea of what to present on stage. All else is decided on a moments notice. The piece evolves according to the interaction between the actors and the feedback from the audience.
Only cranking up the Acceptance frequency will lead to this kind of fluidity of development. And it´s the emphasis on Acceptance, which makes the difference. A daily build has been suggested since long. But a daily build does not equal daily Acceptance. It´s the daily involvement of the customer that counts. Daily Acceptance is about money. Because the money needs to be satisfied, and only money can exert any power on the software production process.
That´s why other benefits will only be realized once Acceptance is daily:
- Benefit #6: The team will only change toward the better if Acceptance looms over it on da daily basis. Change will only happen, if it can demonstrate a connection to the money. Such connection is ever more easy to see, the closer the customer is. He´s most close if Acceptance is daily.
Should a team do pair programming, reviews, TDD, should it refactor? Only if a positive impact on its performance can be shown the answer is yes. Performance, though, is under most tight de facto scrutiny when Acceptance is daily. Only changes to improve the capability to deliver at the end of the day true value are worthwhile to undertake.
- Benefit #7: The code will only change toward better inner quality (aka evolvability), if it’s under constant pressure. Daily Acceptance puts it to the test daily. Every day unforeseen changes can be chosen for delivery in the evening. A code base not highly evolvable will break quickly under this kind of stress. That´s a feature of Spinning, not a drawback. It´s better to see code break in a couple of weeks or months instead of years. Fail fast is true for evolvability, too. If the code base is still small, it´s easier to change design/implementation habits that lead to its breakdown.
The Elastic development process
Spinning very specifically is about software development. Its framework knows about the stuff that gets produced. This is different from Scrum or Kanban, which can be applied to all sorts of efforts. Both are product or even industry agnostic. Spinning is not.
Spinning is ambitious. Daily Acceptance is easy to accomplish feat. Therefore Spinning needs to help as much as possible to reach this goal. Here´s the basic Spinning process. It´s a production process transforming requests into working software.
Every day the process is progressing, every day it rolls value out the door. Progress is achieved by two activities: develop and accept. First working software is developed, and then it´s accepted; and so on…
Development itself is an activity to “run in circles”, to be done iteratively over the course of a progress cycle: at least once, but maybe more often, depending on the request situation.
From the perspective of Spinning development is not a black box. Spinning has an opinion about how software development should be done:
- At the beginning of development the team needs to understand the problem. Too often developers jump onto implementation before they fully grasped what is supposed to be implemented in the first place. This results in a contra productive mixture of problem solving and coding. Also problem solving that way is often done alone; the intelligence of the whole team is not leveraged.
- After understanding comes planning. Planning is needed to make software development a truly collaborative effort. Without planning software development deteriorates to a group activity instead of a team activity. During planning the team develops its idea of a solution to the just analyzed problem. This greatly helps collective project ownership.
- It´s only after planning that implementation can start. During implementation developers individually work on code to contribute their share to the overall progress.
- Finally the implementation needs to be checked before it can be handed off to Acceptance.
Each of these fundamental steps again consists of sub-steps. Some of them are established and self-explanatory, some need clarification.
What understanding means, seems to be obvious. But in fact it is not. Teams often brush over understanding a request in order to get to coding more quickly. This can be seen in many Coding Dojos, too. Even the simplest Code Katas are not really understood before someone fires up an IDE and starts hacking away on a test; this leads to more refactoring than needed.
Spinning tries to slow down teams in this regard. High overall velocity can only be achieved if a team has a solid grasp of the problem.
- Understanding a request requires first to analyze it: what´s the goal, what´s given, which resources are needed, what technologies could be helpful, have similar problems been solved already etc.? These and other questions need to be asked. By analyzing the request usually also a first approach to solving the problem is found.
- To solve the problem and move it downstream towards implementation – keep the delivery at the end of the day in the back of your head! –, the request is sliced. It´s decomposed in sub-requirements until the team identifies at least on slice it is confident to be able to implement until the end of the day; or it has identified enough uncertainty to warrant further learning through a spike solution.
- Triaging is needed to select the request(s) or request slice(s) to tackle until the end of the day. Each day the priorities can change for the customer or other stakeholders.
The order in which to analyze, triage, slice is not that important. Sometimes triage needs to be done first to zoom in on a request to actually analyze. Sometimes slicing comes right after analyzing to produce chunks that can be triaged. Sometimes the activities are repeated due to a deepened understanding of the problem.
In any case, only after requirements have been analyzed, sliced and triaged should planning start. Yes, planning. Spinning needs planning. Think of the proverb: “If you are in a hurry, go slower.” Planning is not a waste of development time, but actually a prerequisite for high velocity. Also as should be obvious from Spinning´s high frequency: planning is not “big plan upfront”. It´s “plan a little, implement a little”.
Planning is done in three different modes. And of course planning involves the whole team.
- During planning the software architecture is designed. This means the team defines a structure for the software in non-functional terms. Of course this pertains only to the request(s) currently under development.
- Architecture is only a framework for functionality. Hence planning continues with designing the functional structure for the current request slice(s). That´s what the model is about.
- Finally, once the solution has been designed (in a coarse grained manner) it needs to be decomposed and assigned to the team members for concurrent implementation. Spinning means, all (available) team members are working on the same feature. Spinning favors the feature team over the feature developer; the goal is Work-in-Progress=1.
That way collective code ownership is created in a natural manner. Daily standups become obsolete, because understanding and planning are done collectively, and implementation is planned and executed in a way so each developer knows her part as well as the larger context. Information is disseminated constantly during Spinning.
Whereas the team as a whole understands and plans, implementation is an individual task. Whoever wants to pair program is welcome, though. Compared to the other process steps, though, implementation is a single developer effort. That way the developers can reduce the latency of coding a feature by working in parallel.
Implementation consists of coding and testing. They are the responsibilities of the developers. No code without automated tests. Implementation manifests the architecture and the model in code. Since design and implementation take place on a daily basis, it does not matter much, if “bubbles don´t crash”. Design´s “bubbles” get translated so quickly into code, it´s almost as if developers were design diagram compilers.
Coding is led by explicit design. But coding of course is also designing – but on a more fine grained level than architecture and model. So if a developer wants to use TDD during coding, that´s perfectly ok. However the importance of TDD is diminished in Spinning (compared to XP), since it´s not the sole tool for designing software. Spinning favors explicit design before coding to underline the importance of a big picture mental model, and to support a collective understanding of the design.
The final development step is checking the code quality. Implementation produces a software increment to provide value to the customer. That´s at least the intention of understanding, planning, and implementing a request slice. But does it succeed?
- A continuous build process first formally checks the quality of the result of the previous development steps. Does the code compile, do all tests run flawlessly, can it be deployed to different target platforms?
- As important a continuous build is, it´s not enough. A code review is needed for several reasons. Firstly, only a code review can check if the design has been faithfully implemented. If deviations are not spotted and discussed immediately, the quality of the software structure quickly deteriorated and no common mental model exists anymore. Secondly, a code review is highly effective in spotting errors and deviations from requirements. Thirdly, during code review the whole team is back together to deepen its collective project ownership and share knowledge. Fourthly, during a code review any conventions can be checked.
- Finally, after the build process and the developers have checked the code, quality can be assured by looking at the software from the outside. Some QA surely will be part of the automatic build process, but mostly there will be some work left for humans.
To assure the team of the quality of its increment is an ongoing effort, although it looks like it´s just a process step at the end. Remember: understanding, planning, implementing, checking is done every day. And since people from QA belong to the team, they are involved from beginning to end.
In Spinning there is no “throwing code over the fence” like there is no “throwing a design over the fence”. A day in Spinning is mostly filled with the team members actually talking with each other by collectively understanding, planning, and checking the software.
Spinning only works if a group of developers really is a team – which is not the same. Or when there is no real team yet, Spinning helps to knit together the group members into a team. They almost can´t help but become a team, because otherwise the pull by daily Acceptance cannot be handled.
Spinning is serious about a couple of things:
- Software development is a true team effort. A cross-functional team is needed.
- Software development needs an explicit process to ensure high quality and constant flow. And this process needs to be specific to software development.
- Software development is only as good as Acceptance is.
Feedback and flexibility are increased, and running development in a tight circle minimizes detrimental effects of explicit planning and designing while increasing code quality and speed.
How exactly you do your request analysis, model before coding, organize the implementation or do your reviews… that´s up to you. If you find UML, TDD, pair programming helpful, that´s fine. You´ll soon notice if these tools are useful to keep up with the high frequency of Spinning.
Also Spinning is agnostic to whatever you think you need to wrap around it. You can use Spinning within Scrum to iteratively home in on your sprint commitment. You can use Spinning within Kanban to decrease batch size. Call Spinning an Agile core practice, if you like. In the end, though… Spinning alone should do the job.
View the process steps as items on a checklist. Check them off each day. By doing so ask the team: “What have we done regarding X?” with X being analysis, triage, …, review, QA. Make this your daily reflection habit.
Sometimes you´ll find you do more understanding or modeling than is necessary for today´s goal: deliver working software at the end of the day. That´s fine. Keep the insights in the back of your collective head for tomorrow. Just be sure to progress every day. Sometimes your steps will be bigger, sometimes they´ll be smaller. It´s not the size of your progress steps that matters much, but to continually progress. Deliver value to the customer each and every day. Call some request slice done each and every day. That will make your customer happy; it builds trust; and you can go home relaxed each night. No pending issues, no unfinished work. Spinning thus not only tries to be very true to the Agile manifesto, but also to the Cult of Done manifesto.