Some background before I get into the detail, I’ve been developing small, medium and large ‘shrink wrapped’ products for the past 12 years and before that I worked on large multi-million pound in house projects.
Why do I give this background? Well it’s to set context in relation to this post from @Martijnlinssen where Martijn questions whether Agile can be used effectively for product development. I read into Martijn post that whilst Agile might work for project development it doesn’t work as well (if at all?) for Product development. I chose to disagree with Martijn on this point and responded with the comment:
I’m not sure from reading this that you actually get agile (sorry Martijn).. Whilst I agree Agile is not for everything, Agile can be a highly effective way to deliver software (and even commercial business) projects.
What it isn’t is throw all control in the bin and fly by the seat of your pants… What it is is a model whereby accountability lies with the dev team and not some project manager miles away from reality of day to day decision making.
The controls are very adequate and personally I’ve used it on dev teams of 80 or so people… Based around scrum of scrum hierarchy … However, that said I also like high level governance in place for really complex implementations.
We debated this via twitter some more and a few more comments were added to the original post. I think we got to the stage where we agreed on some parts but not all, i.e. Martijn came up with some very interesting follow up questions/concerns:
How much money gained during dev is squandered in test and maintenance, compared to waterfall?
When does the benefit of not writing everything down turn into a concern?
How is the transition made from build to test to product for maintenance?
Can you just outsource your finite product once Live?
So, I’m writing this post to share my thoughts (and learning’s) around these questions. I say leaning’s as I have the very same concerns in the past. If you don’t know what Agile is then look here for a very basic overview of Agile.
Now, if you just took the overview and went off to develop products you’d be in a big mess in no time at all. In my experience, there are some other very key components that are essential for success. Assuming that you have your development backlog, velocity and your sprint schedule defined, I’d advise that you also need:
- A solid system architecture in place before you begin – my approach is to deliver the blueprint and prove it out if necessary with a proof of concept (POC) in Sprint Zero… you won’t see mention of sprint zero in many (if any) Agile books, but it’s my preferred way to prime the Agile process. Start building without this and you’ll hit dead ends time after time and end up reworking huge chunks of the product.
- Design patterns and framework for the user experience and interaction, i.e. it’s no good if different parts of the product look, feel and work differently. Usability is absolutely key and should be built in from the start as opposed to painting it on at the end.
- Good coding guidelines around solid engineering principles such as defensive programming and more recently test driven development, without these it’s very easy to write poor quality code the costs a fortune to maintain using Waterfall or Agile.
- And the secret ingredient… A team of highly proficient people who understand how customers work and what problems the Agile stories are trying to solve… I can’t stress how critical it is that developers and testers understand the needs of the customer, otherwise they just build what they are told and we all know that’s a recipe for disaster. It’s also a good idea on complex systems to supplement the developers and testers knowledge with highly specialist domain experts (Business Analysts) for things such as compliance and complex processes.
Some of the techniques I really like in Agile are daily meetings, which are fantastic to keep everyone on track, the burn down charts to show you exactly where you are, and the retrospective reviews, which are a brilliant way to look at what you’ve just done and how you did it and improve it for next time around. All of the best athletes do this, the military do this, and it’s a great way to continually learn and increase the capability of the team.
So, coming back to Martijns questions…
How much money gained during dev is squandered in test and maintenance, compared to waterfall?
None of it if you follow the principles above… and if you structure the sprint teams correctly you can save money by being more effective, i.e. the formula I use is:
Developers and Testers working together as part of a 6 person scrum team, normally to a ratio of 3 devs, 2 testers and a scrum master (Team Leader)… this means that you test as you go, can fix issues as they are found and deliver better quality software at the end of each sprint.
For larger systems, I also prefer a separate system/integration test team that don’t work as an agile team. This team doesn’t retest everything, they specialise on integration, regression and beta testing.
As for maintenance I don’t use agile per say for that either. I prefer a separate sustained engineering team that are dedicated to respond to any issues found post release quickly and efficiently.
If I compare this to my experience of waterfall, where all the specs are written up front by BA’s who understand the customer, handed to development to code up who don’t understand the customer, then passed to testing for QA who try and piece things together. It’s much less efficient and makes no attempt to build quality in as you go, and if the project is a long running development there’s a real chance the requirements have changed since the BA wrote the original spec. The system is out of date the minute its delivered.
I’ve seen many more waterfall projects fail than I have Agile, generally people are more connected with what the goal is and what needs to be done to ensure delivery.
When does the benefit of not writing everything down turn into a concern?
Great question, of course nobody says you don’t have to write anything down, you document the system in a number of ways, first you have the architectural blueprint and the interaction patterns, then you document complex business rules and compliance and finally you document in the code. From my experience, documentation is used to define and not to maintain, i.e. I’ve never met a developer who goes back to original spec to fix a problem, the best ones read the code and trace the problem through a debugger.
How is the transition made from build to test to product for maintenance? Can you just outsource your finite product once Live?
Okay, so the sprint teams deliver running code, by running code I mean it is developed, working and tested within the team. For multi-team and multi sprint projects each sprint deliverable is then assembled (using a versioned build process) and handed over to the system test team who check all the component parts delivered by the sprints work together. This takes the form of an initial smoke test, thorough integration testing, and full regression test to ensure the new deliverable hasn’t broken the system. Any bugs that are found are captured and these are fed into subsequent sprints, or more likely that you have a one or more bug fixing only sprints only once you’ve reached feature complete lockdown…. This may also include a period of external beta testing, but the process is the same.
When the bugs have been resolved the product deemed fit for purpose, it is versioned and shipped.
So then you start working on the next version of the product and repeat the process from the top. In the meantime you have to sustain the product you have just released. It’s even more important here that the sustainability team understands the customer and the domain. Whilst Agile could be used here to produce a scheduled service pack which contains a defined body of work, Its not good for producing a single hot patch which are normally a few days in duration.
Can you outsource the product once live?…
I don’t, but it’s possible as long as the sustainability team has a certain amount of product/domain knowledge and can read the blueprint and the code. I’ve tried this in the past based on specs only and it fails miserably, even with waterfall, it fails miserably… as at the very least you need a link back to someone who understands the customer and the domain.
Agile is about people… and not about the Project Manager
All of that said… the most important part of Agile for me is Ownership, Accountability and Empowerment. In a high performing Agile team, the traditional Project Manager feels uneasy and disempowered, they may feel out of control, as the team are empowered to make their own decisions. The old style command and control ‘tell do’ Project Manager will never succeed with Agile and will fight tooth and nail against its adoption. Whereas the new breed of Project Manager who can trust his people and continually develop them through coaching, will soon reap the benefits of delivering much more through their people than they ever could through command and control.
How do I know that?
This is my own story… I am that person.
Stuart Lynn - Masters Athlete 
13 replies on “How to make Agile work for product development… It’s all about the people”
Great Stuart! Thank you very much
Alright, I get some of your points – but not all
I see a high degree of specialties. Developers and testers needing to understand the customer? Business analysts and Project leaders do already of course – doesn’t that cost an awful lot of money? How about offshoring development and test to India?
Maybe what you are saying is this: business analysts, the linking pin between customer and code, are not up to the job – they make a lot of mistakes. Having people down the line spotting the flaws in their functional designs in an early stage delivers great value to the project, resulting in time and cost saved at the very end
There must be a reason Stuart, there must be a trade-off. You mixed up writing everything down with writing anything down, but basically that is my very point. We’re talking about loosely-coupled architectures and applications, and here comes Agile hard-coupling people to projects and products – in a world of outsourcing and offshoring!
My version of working Agile: just hack and cuddle away during most of the initial phase, start writing down that which is good. Make sure that at the end of dev you have the full functional specs on the table, so you can throw testers at it who can read and cost $6 an hour. That will also be a fine preparation for maintenance, and do away with the previous-century need of being dependent on people for a software product
You made some good points and cleared things up, but I still don’t see exactly why and where Agile would beat waterfall, or IAD / RAD / RUP
Anyway, thank you very much for the dialogue, this fine post and hope to continue
Great follow up questions Martijn
Hack and Cuddle… great term, I love it.. I’ve come across this a lot on my travels, but it doesnt normally end in cuddles, mostly (S)ack unfortunately.
My preference is to spend money up front and build quality in at the beginning as opposed to testing it in at the end. Yes it may cost you more initially but you save money in the longer term and it proves a much better TCO… However, many CFO’s don’t get this and it so Dev Managers forecast/promise lower costs initially to get the project started, only to see costs spiral out of control later in the day.
My experience of Agile also works for outsourcing as there is no geographical requirement for the sprint teams to be all in the same location. It does rely on people working collaboratively though as opposed to lobbing code backwards and forwards. I’ve got to say I’ve also tried this, to my cost… it just doesn’t work.
I’ve worked with outsource Indian teams on co-development/testing and it can work very well, but in my experience it can also be a nightmare if it’s viewed as a simple customer/supplier relationship. You’ve heard the saying “you get what you pay for”… well its true, you get what you pay for…
My advice to anyone doing this is to embed some team members from India (or wherever) in your local team for a period to give then basic domain and product knowledge. This is the same as training someone in C#, once they know what they are doing they are much more effective than having to work it out for themselves.
I also feel it could work for loosely couple architectures, again though the architectural blueprint and the interfaces need to be laid down up front.
This way of working isn’t as expensive as you might think… and the end product is easier to maintain in the long run.
Thanks again for the comments Martijn
Good post and some great comments – and I’m not just saying that because I’ve been planning some similar blog posts myself!
With regard to “offshoring” I think a key point on whether agile techniques are suitable is in the distinction with “outsourcing”.
I have remotely managed a development team in eastern Europe in the past: we recruited the staff ourselves (including a very organised and efficient team leader) and ensured a close working relationship with the domestic teams. I also spent a great deal of time with them in person.
Under these conditions, an agile approach worked very effectively.
What I personally would not attempt to do would be to manage an offshore-outsourced team using agile techniques. When you have no direct control over the people – no real idea of their quality or background – then simple risk management demands a much more prescriptive approach.
To be honest, things are not really much different for local outsourcing – except that it’s more practical to build your own confidence in the ability of the people doing the work, which may reduce the risk to the point where the benefits of agility are worthwhile.
This brings us back to one of the key requirements for agile to work – TRUST. If you don’t trust the team, then you can’t afford to employ any system that empowers them… but I’d suggest you have bigger problems than which Project Management methodology you follow.
PS Can we please stop using “Waterfall” as a catch-all for traditional “big design up-front” processes? Pure Waterfall was originally described as a model of a flawed, non-working, system. Even in my own university days it was only used to teach the phases of a project lifecycle and not as a “real” process to use! This is a serious point, as I often feel that the obvious flaws of Waterfall make it an easy straw man and muddy the water when discussing the relative benefits of agile v prescriptive approaches
Let me rephrase that: you have been on both sides. Where and why does Agile beat waterfall?
Some ways that Agile beats waterfall …
It builds quality in from the start rather than retrofitting it at the end, which ultimately delivers a higher quality product that is easier and cheaper to maintain post release.
It derisks a project by delivering running code form sprint #1, ie you see what you’re getting long before you would with Waterfall, which in turn builds confidence across the business.
It improves output of the development team by motivating them that they make a difference and are not just code monkeys.
It unleashes the creative power and problem solving abilities of the entire team as opposed to the handful of business analysts.
It requires less wasted paperwork and red tape than Waterfall which saves both time and therefore costs of development.
It allows changes in business requirements at any time, within one sprint cycle, without having to go back the the analysis phase as you would with Waterfall.
It encourages people to take ownership for their own work, ie quality is the responsibility of the developer writing the code, not the responsibility of the tester…
I could go on and on, but how does that sound???
I think I’m getting how Agile works, and thank you for that – but it appears to me that there’s a much bigger picture behind it all
Thank you for that Stuart, I’ll let this sink in, but you’ve been about a dozen times more helpful than my ex-colleagues at Capgemini, who failed to answer any question
I’ve worked with variations of waterfall for about 20 years, and been a long time Agile sceptic.
In the last 12 months I’ve become completely converted. Not that Agile is good and Waterfall now bad, but that Agile has an equal place at the table.
I think the comments so far (including in your blog post, Martijn) nail most of the important issues, but I can add the following from my experience:
1. I find it helpful to think of processes in the same way as tools. Choose the appropriate tool for the appropriate job. Agile has worked brilliantly for me with a small team developing a product that’s not safety critical. I would not use Agile for the software that lands a plane in fog.
2. Similarly, taking the tools analogy further, the same tool can produce remarkable results or poor results, according to the skills and experience of the craftsman using it. Rigour and discipline are the traits of the best practitioners in all industries. Agile in the wrong hands is like giving a power tool to a child.
3. Stuart is therefore absolutely right that people are the critical factor. But not just because of their skills and experience in applying technology. In my development, using Agile meant that the developers have become immersed in solving the business problems themselves, rather than building to someone else’s requirements. There’s definitely a social and behavioural dimension. They have contributed good ideas and clever, innovative refinements in ways that I simply have not seen in all the time of using more traditional methods. As the ‘product owner’ I have been humbled by the value they have added that I would never have come up with.
4. It’s a chilling thought for me that I just would not have been able to recruit the two outstanding developers I now work with unless we were using Agile. The best developers in web (SaaS) applications will not work on waterfall.
5. Documentation and writing things down. I have seen most processes you can mention suffer from poor documentation. That’s down to the practitioners not the process. In Agile (done properly) the tests are written before the software and therein you should find the requirements and specifications. In addition to the tests (Agile is a ‘test-driven’ methodology), we use an additional stage of ‘behaviour-driven’ design. The two combined mean that both syntactic and semantic testing is automated from the outset. And the comments in those test scripts constitute a lot of documentation. But it is by definition maintained, because it has to match the code otherwise the tests fail.
I accept I am in the early days of the transition, and the maintenance period will be another phase of learning. Already we have needed to add a decision log to record the rationale for some of the more complex decisions. But whatever we may have yet to learn in ongoing maintenance, I would not be approaching the imminent launch of our product with such confidence unless we had used Agile, nor for about another 6 months as we would not have been able to prioritise so ruthlessly to achieve minimum viable product (MVP).
Let’s do a separate thread on outsourcing and near/far/in/out/hokey-kokey/off-shoring, there are so many other factors to that debate than just methodology!
Thanks for the comments Guy…
It’s good to hear that you also support the principle that people more so than process or tools are the critical factor.
I also look forward to hearing your thoughts on this Hokey-Kokey methodology of outsourcing… Although I think I may have heard of it already… Is that the one where you just as you gear up to take the product out of the country, you bring it back in again… is that what it’s all about… yeah?
Stuart – Great post.
I was alarmed by
“What it is is a model whereby accountability lies with the dev team” as I have had experience of R&D teams driving development to the detriment of the customer. However this assuaged my concerns
“And the secret ingredient… A team of highly proficient people who understand how customers work and what problems the Agile stories are trying to solve… I can’t stress how critical it is that developers and testers understand the needs of the customer, otherwise they just build what they are told and we all know that’s a recipe for disaster. It’s also a good idea on complex systems to supplement the developers and testers knowledge with highly specialist domain experts (Business Analysts) for things such as compliance and complex processes.”
Best achieved by having a representative from customer services in at the front end, no?
Hi Louise, thanks for the comnents
With regards accountability lies with the dev team… Knowledge imparted from customer service or any other front line function close to customers is also critically important and should be sought/used whenever available.
However, I would suggest we are all customer services representatives, regardless of our role in a company, and the more people you have in a company that believe and behave this way, the better the product and the overall customer experience.
[…] Stuart Lynn's Blog HomeAuthor « How to make Agile work for product development… It’s all about the people […]
[…] few weeks back I wrote this post on How to make Agile work for Product Development. As a build on that post I’d like to share how I’ve used Agile to successfully deliver […]
Reblogged this on Technology Matters.