Lean manufacturing, the precursor to the “Agile” methodologies, has the concept of “Stop the Line”. When a defect in the product is identified, the entire assembly line stops to locate and rectify the factors that caused the defect.
The major difference in a software development “line” is that there is no physical assembly line, so it is easy to blur the distinction between what is and isn’t part of the product and hence the “line”.
In the Lean manufacturing model it’s acknowledged that the cause of the defect may be more than just a faulty component. It may be the tools, processes or even the skills of the people involved in the manufacturing of the component that contributes to the defect. With the line stopped, the right solution can be found before production resumes.
In software development however, development continues. One of the problems Adrian points out is that
if developers keep working while the build is broken, they build up a large backlog of commits which makes it more difficult to identify which revision broke the build
It goes further than that however. By continuing to develop, the team and management are assuming that the defect was caused simply by a mistake in coding of that feature or the build process. What if the problem is in the development process, the tools or the experience of the developers involved?
Adrian goes on further to suggest that some companies go a little closer to a “Stop the line” approach by putting
an embargo on commits or close the source tree to prevent any further changes from being committed
Once again, development doesn’t stop, we simply stop putting things on the assembly line. Once the build breakage is resolved, all these potentially broken changes are pushed through.
By stopping the entire line, your development team can not only address the current defect, they can also perform a “Root Cause Analysis” of why the problem occurred, leading to better processes, tools and people.
So why do so many companies see “stopping the line” as a waste when it is the complete opposite?
I believe it’s based on a management perception that if you aren’t developing code directly related to the final product, in other words features or bug fixes, then you are not being productive. In addition, there is a belief that the number of hours spent coding directly relates to the productivity of the team. So a team is discouraged from taking the time to not only improve their tools and processes, but also to analyse what needs improving.
]]>I guess it should have been expected, but what was interesting was that it seems the delay is not due to unexpected issues in the fit-out (as in water damage, etc) but rather the delay in the supplier getting the taps to the company doing the work.
Talking to the plumber, the problem lies in the suppliers not having stock sitting in local warehouses. Now this wouldn't have been a problem, but the time from agreeing to do the project, and it starting was very quick. As such, the time for the delivery of taps was longer than the time until they were needed. So if we weren't able to kick off this project so quickly, then they could have ordered those items in advance enough to get them here in time.
This got me thinking about Lean development practices and the “Just in Time” approach. If we consider that the aim is develop something “just in time” for when it is required, then it is possible that an opportunity may arise that, to take advantage of, would reduce the available time to develop and subsequently cause delays.
Of course the trade-off of doing “Just in Time” is that you aren't building a stock-pile with all the inherit costs and problems. It does however mean that the critical path analysis for taking advantage of a sudden opportunity does require you to know the “Just in Time” periods that could affect you.
]]>
At Ephox we are extremely good at making the impossible possible, just take a look at EditLive!. The things we did in the early days were not possible with the limitations of the Java APIs, so we found a way around them. As such, it is possible to continue with a feature beyond the current return on investment of the feature.
What we need to do is find a way of identifying when to stop the investment in a given feature, mark it as "failed" and move onto the next most valuable feature. To do this however, you need to know what are the conditions by which you define something as having failed.
We recently moved to a tri-estimate approach1 where all stories include a Best case, Worst case and Most Likely estimate. These estimates not only give us an indication of the risk associated with a feature, but also a basis by which to determine "failure".
My framework for "failing" a story is as follows. Once we hit the Most Likely estimate, we re-evaluate the Worst Case estimate with the knowledge gained so far. Assuming the revised Worst case is an acceptable investment in the feature, the new value is then considered the "line in the sand". Once we hit the Worst Case estimate, we review, asking how much longer to go to completion. If the time to go is acceptable, then this is the "failure" time. Once that time has expired, the story fails.
So, for example, figures of 20 and 40hrs are given for Most Likely and Worst Case estimates respectively. At 20hrs, the team revises the Worst Case to 45hrs. It is accepted that the features value is worth 45hrs, and development continues. At 45hrs, the team says there is an additional 3 hrs to go to completion. This final amount of effort is short enough that development continues for the 3 additional hours. At the end of that time, we "fail" the story if it's not completed.
Now of course, there are exceptions to this, but the aim is to identify when a feature is just going to keep going and stop it.
1 – Doug discussed the idea in his article Estimations – Best, Expected and Worst ↩
]]>I totally agree with the view that today's developers require far more social and people skills than evidenced in the traditional view people have of the developer. I also think that the Agile practices help focus a development team on the needs of the client and hence force engagement with the business users, resulting in the need for and development of these skills.
Where Suneth and I depart in our views however is in his assumption that technical skills don't matter for a developer. His assertion that
Anyone with a healthy brain can learn any programming language and write good code with some guidance and practice. But it is not easy to train someone to behave a certain way or teach some values like being positive or working as a team.
I think misses the fundamental training in Software design that engineers gain during their degree. There is a big difference between "Programming Skills" and "Language Knowledge". To borrow from Dylan's comment to Suneth's post
There is [the] art of developing quality software – a strong degree of craftsmanship involved, which separates code-monkeys from true engineers.
I also think that Suneth sells himself short in his comment that
… technical skills of a programmer should not be the main requirement while hiring. For example, prior joining Ephox, I was a .NET developer.
I'd disagree with Suneth suggesting he didn't have the technical skills of a programmer, we wouldn't have hired him if he didn't. What Suneth lacked was commercial experience in our language of choice, Java, but his technical skills in developing quality software were evident and why we hired him.
As a manager, when I'm looking for new recuits I'm evaluating the whole package, social and technical and weighting them equally. In the interview process, the face to face covers the social, and the programming exercise covers the technical. In one way we differ from the traditional though in that our programming exercise doesn't require the canidate to program in Java. It's their analysis, design and development skills and philosophies we are interested.
]]>
As I mentioned in my recent post on "XP Practice Champions", in our first XP Adoption review we identified stand-ups as a practice to focus on and improve. The introduction of the "Talking Car" was one of the ways we focussed on improving stand-ups.
So how is it used? In our case, the car is tossed to someone randomly, that person then talks about the following
before tossing it to someone else in the group.
As part of our continuous improvement, we recently reviewed our stand-up and decided it needed to be more story focussed. So the new list of topics are
With this list, we can address why a story wasn't completed, what we can do to complete it, advise the client of the delays and continue to communicate to the entire team what is being worked on.
By focussing on successful story completion and communication of progress to the client hopefully this will also help with our improvements to Weekly Iterations.
]]>In our first review, we identified Test Driven Development (TDD), Daily Stand-ups and Iteration Demos as the practices we would get the most value by focussing on.
To inject some fun into our practice focus, we introduced the "Talking Car"1 for Stand-ups. For TDD one member of each team volunteered to be the TDD representative for the week, during the weekly retrospective. Their job was to remind the team during the stand-up that we were focussed on TDD. Finally, we made it the responsibility of the "client" to hold Iteration Demos to the business.
In our most recent XP review we have identified Root Cause Analysis, Planning Game and Weekly Iterations as the practices to focus on. We will continue to work on improving the previously identified practices, but we felt that as a team, we would gain the most value through the new practices.
The question is, how do we remind the team of our commitment to improving these practices?
Atlassian recently posted about their Agile Process and one thing they mentioned caught my attention. Chris explained that they "have practice champions for many of the more challenging practices".
I'm really interested in how we could use Practice Champions to help focus on and improve the 3 practices we have chosen. I'm hoping these champions can bring some fun and energy to the adoption process and galvanize the team behind improving some fundamental XP practices.
]]>An unavailable product owner perpetuates the wait time and creates waste
Having experienced this in the past, I can't agree more.
At Ephox our Product Manager plays the role of client in our iterations. As part of his role he spends a certain amount of time travelling. In the past we tried to continue development while he was away. What we found was that, even though he was available via email and phone, his lack of availability within the office while a feature was development caused delays and in some cases wasted work.
The way we've dealt with this, especially with an increase in Product Managers recently, was to have agreement that, as the client, if you were not available your development release would stop at the end of the iteration. The team would then work on stories in the next iteration for the other product manager or spend time on process improvements within the Engineering team.
]]>For developers, documentation is extremely useful for the those who come after, even if it's you in 12 months time. This documentation however is only useful if it's up-to-date. Unfortunately in most cases it's written, read and never looked at again.
When I was consulting, and prior to my introduction to Agile practices, I often worked with organisations that didn't particularly want to spend time on documentation. This wasn't because they believed it wasn't useful, it was more a cost saving method. Still wanting to provide future developers some form of documentation I became an advocate for heavy commenting of code. Hence, the code became the documentation.
With my introduction to Agile practices a few years ago the idea of "documentation in the code" has moved on to incorporate and focus on atomic tests. The application of the concept of waste from Lean Software Development on formal documentation also supports the use of atomic tests as documentation (unless the documentation provides some other value than the fulfillment of the process).
So does code (test cases) as a replacement for formal documentation meet the requirements of managers who are looking for "People Independence"? It does if they are looking for a way to fulfill the need to pass on knowledge to future developers. In addition the added benefits of atomic test on quality and confidence for future developers to make changes and maintain current functionality is immeasurable.
]]>When we adopted XP (eXtreme Programming) we undertook to have a retrospective at the beginning of each development iteration, preceding the planning game. With weekly iterations, we have a chance to reflect on the previous weeks pluses and to formulate some changes/improvements (deltas) identified from the week.
In the article the author made the following comment,
In fact, looking back is only half of the retrospective pattern. Reflection is not learning. To bring about learning and improvement, it is necessary to identify areas for improve and explicitly document a brief action plan for which the team becomes accountable.
We regularly come up with a number of delta's and then choose the highest priority ones to be tackled during the next iteration. We even assign someone to "own" the task. So we are on track to learn and improve however what we struggle with is when we have too many delta's to be done in a single iteration.
Currently we review the previous retrospective deltas at the beginning of the retrospective and copy any un-addressed ones to this retrospective's delta list. The problem with this is that the list is getting bigger.
I'm not really sure what the solution to this is yet so if you have an suggestions I'd love to hear them. For now, we'll continue to tackle the most pressing or productive delta's and keep reviewing the previous one.
]]>Deborah's post referred to and quoted from an article by Rachael Davis entitled "How To: Live and Learn with Retrospectives". The quote from Rachael's article included the following sentence.
Without these in place, conversations are likely to be full of criticism and attributing blame
Rachael's comment, when put into context of her article, is about avoiding a situation resulting in blame, however, while the commentor's remark may have been facetious, it seems "blame" in retrospectives is a reality.
Attributing blame, be it in a retrospective or in the development process seems to me to contradict some important elements of eXtreme Programming.
The principle of Accepted Responsibility and the practice of Collective Ownership (which comes out of the Shared Code practice) both imply that the team accept and own the decisions collectively. Pointing the finger tends to do nothing but breed resentment and cause people to "switch off" to potential solutions to the problems.
Finally, attributing blame in a critical manner ends up breaking the core value of Respect.
I think it's an important role for a manager to encourage an environment where people feel "safe" to raise issues in a retrospective without feeling that blame will be attributed.
]]>