I'm now in a session called "Agile: Why Should Your Business Care?". We all talk about agile, but what does that really mean for your business, and what does your business want from IT/IS?
Interesting opening video, about how Standard Life has co-located IS and business people, creating strong multi-disciplined teams. The results? Very happy stakeholders, and industry awards for their innovative technology products.
Standard Life has about 500 application development people. Standard Life are also a key exponent of SOA, and a reference customer for IBM and other companies for their implementation of SOA. They say SOA and Agile are really complementary.
So what does Standard Life business want from IT?
1. Value for Money - avoiding waste and delivering just what is needed.
2. Productivity - have to be able to demonstrate efficiency in development.
3. Predictability - the business needs to know when they will get the software, and what it will cost.
4. Quality - of course, quality matters.
But what they don't want, is lots of talk about agile or software development methodologies!
Instead, talk about value for money, productivity, predictability, and quality - and they start to get the message.
So what did Standard Life do to change?
Standard Life like the concept of Lean, as per the Toyota manufacturing concept. They found a book that really helped: Lean Software Development by Mary and Tom Poppendieck. This book really takes the Toyota concept, translates it, and adapts it to software development.
Standard Life also ran experimental projects. Short projects of about 3 months, where they really put agile principles into practice for the first time. It was a great learning experience, and imperative before trying to scale agile up.
Effectively they implemented agile one small step at a time, allowing their agile adoption to gradually snowball, as they learnt more about the practices.
But it took courage. Experimenting on projects takes courage. Breaking away from approaches that have been used for many years, takes courage.
Standard Life also did formal training, with industry-leading people like Mary and Tom Poppendieck, in order to build on their knowledge. They remember asking Mary how they should scale agile up to run big projects? Mary's answer: "Don't. You shouldn't run big projects".
Of course, what she meant was to break big projects down, and run them as several smaller projects. The bigger a project is, the more likely it is to fail. Maybe that's common sense, but it's not necessarily common practice.
Gartner did a benchmark study and found Standard Life to be in the top quartile in terms of their application development performance. And they credited this to their advanced use of SOA and agile development.
They are implementing agile team by team, building on this success.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Subscribe
Agile Business Conference 2008 – Agile: Why Should Your Business Care?
0 comments 
The State of Agile Development
One of my colleagues sent me this link to a survey about The State of Agile Development by VersionOne, released in August 2007.
I was particularly interested to see some of the business benefits of agile development experienced by respondents...
* 90% saw Increased Productivity
* 85% saw Reduced Software Defects
* 83% saw Accelerated Time-to-Market
* 66% saw Reduced Cost
Although that sounds great, the danger of course with any survey is it's impossible to control who responds to the survey. And that means it might not be a representative sample.
Being critical, what if all the people that have found agile to have adverse affects have simply given up on it and therefore didn't participate in the survey?
So, from my point of view, I'd take any survey with a healthy pinch of salt. But with that caveat aside, I thought it was interesting nevertheless.
0 comments
Why Most IT Projects Fail. And How Agile Principles Help
I recently wrote a blog post explaining why most IT projects fail to meet expectations.
As a follow-up, here I take a quick look at the common reasons for project failure, and how I think agile software development methods and agile principles mitigate these risks and issues.
I have a strong view that agile methods help significantly with a lot of these areas of project risk, although I'm sure not all. This is an enourmous subject, so I can't really do it justice and keep this blog post a reasonable length. So you'll just have to take or leave my comments on face value :-)
| Common cause of failure | How agile helps |
| Project Initiation & Planning Issues | |
| Unclear or unconvincing business case | Agile principles don't help directly with the busines case - in fact it can be hard to make a business case for agile projects due to their agile (i.e. unpredictable) nature. However the principles of incremental delivery and frequent deliver of products can help to get an initial solution out, test the proposition with the market and get real customer feedback to inform the priorities for further development. |
| Insufficient or non-existent approval process | Agile business cases and new business propositions benefit from the same diligence and challenge before investing large amounts of money, just as in any other approach to development. |
| Poor definition of project scope and objectives | Agile projects also benefit from clear definition of scope and objectives, even though details are allowed to emerge throughout the development. |
| Insufficient time or money given to project | If only agile could solve this! |
| Lack of business ownership and accountability | Active user involvement, or involvement from a key user representative in the business, creates an environment that fosters close collaboration and cooperation. |
| Insufficient and/or over-optimistic planning | This is an interesting one. I (like many agile enthusiasts) believe that it's practically impossible to plan every detail of many software development projects up front, hence expectations are better managed by active involvement in the project, frequent delivery of product on an incremental basis. |
| Poor estimating | Agile methods provide some important principles to help with accuracy of estimating: estimating should be done by the whole team as a collaborative process; tasks should be broken down into micro pieces (ideally less than 1 day) so progress is measurable on a daily basis; 'velocity' is calculated on the number of estimated hours delivered only when a feature is 100% complete, providing a gauge for how much development can be safely included in future iterations. In non agile methods, this approach can also be adopted and is known as 'earned value analysis'. So even if you're terrible at estimating, this approach can be self correcting as long as you're consistently terrible :-) |
| Long or unrealistic timescales; forcing project end dates despite best estimates | Agile projects encourage short and regular iterations, developing the software and delivering working product in small bitesize pieces. |
| Lack of thoroughness and diligence in the project startup phases | Rather than diligent and thorough planning, agile principles propose to deliver small increments of working product and get continuous feedback from active user involvement throughout the development cycle. |
| Technical & Requirements Issues | |
| Lack of user involvement (resulting in expectation issues) | Active user involvement and continuous feedback is one of the most important principles of an agile approach. |
| Product owner unclear or consistently not available | One of the reasons product owners are unclear in traditional projects is because they are asked for far more detail than they can handle, too early in a project and when they cannot visualise the solution. Instead, agile requirements are kept lightweight and visual, and delivered just in time for a feature to be developed. Availability must be forthcoming for agile principles to work, as it's essential for constant collaboration. |
| Scope creep; lack of adequate change control | Agile projects may stick to the broad scope of the project, but requirements are allowed to emerge and evolve. However the project must include non-essential requirements at the outset, in order for emerging requirements to be traded with original scope. |
| Poor or no requirements definition; incomplete or changing requirements | Agile projects expect requirements to be incomplete and changing. That's the nature of software. Instead of resisting this, agile projects provide for it by allowing requirements are allowed to emerge and evolve. Requirements being produced on a feature-by-feature basis, just in time to be developed, helps with definition because it breaks this intensive task into small pieces instead of being a mammoth effort up front. |
| Wrong or inappropriate technology choices | Agile projects can surface inappropriate technology choices early, as they encourage frequent delivery of product on an incremental basis. Testing is integrated throughout the development cycle, testing each feature as it's developed. Doing so can help to ensure inappropriate technology choices are identified early, before too much of the software has been developed. |
| Unfamiliar or changing technologies; lack of required technical skills | Agile methods don't help directly with this issue, although can help to surface such issues early, and make them visible. |
| Integration problems during implementation | Agile projects are delivered in short iterations, with testing integrated throughout the development. This requires continuous integration of the code and frequent builds, removing the need for a lengthy or problematic integration phase at the end of the project. |
| Poor or insufficient testing before go-live | Testing is integrated throughout the development. |
| Lack of QA for key deliverables | Working software is the key measure of progress, as the software is developed and delivered in regular iterations. This helps to ensure that the adequacy of any other deliverables is highlighted early and made visible. |
| Long and unpredictable bug fixing phase at end of project | Testing is integrated throughout the development. |
| Stakeholder Management & Team Issues | |
| Insufficient attention to stakeholders and their needs; failure to manage expectations | Active user involvement ensures two way feedback throughout the development. |
| Lack of senior management/executive support; project sponsors not 100% committed to the objectives; lack understanding of the project and not actively involved | All projects need this, agile or otherwise. |
| Inadequate visibility of project status | Agile projects provide clear visibility of measurable progress on a daily basis. |
| Denial adopted in preference to hard truths | Humans, eh? Who needs 'em! |
| People not dedicated to project; trying to balance too many different priorities | I don't think this ideal is specific only to agile methods, but agile principles propose small, multi-displined teams dedicated to the development of the product. |
| Project team members lack experience and do not have the required skills | Agile principles may help to surface such issues early, as they may well be evident in early iterations of the software. Frequent delivery of iterations and continuous testing can help to mitigate this risk when it might otherwise go unnoticed until much later in the project. |
| Team lacks authority or decision making ability | Agile teams must be empowered. |
| Poor collaboration, communication and teamwork | Close cooperation and collaboration between all stakeholders is essential. |
| Project Management Issues | |
| No project management best practices | Can be an issue when applying agile methods, unless using an agile management practice such as Scrum. |
| Weak ongoing management; inadequately trained or inexperienced project managers | Agile methods and principles are just management tools. A fool with a tool is still a fool! |
| Inadequate tracking and reporting; not reviewing progress regularly or diligently enough | Agile practices have daily status reporting built into the process, providing clear visibility and measurable progress on a very regular basis. |
| Ineffective time and cost management | Daily visibility of measurable progress. |
| Lack of leadership and/or communication skills | Sadly, adopting agile principles doesn't make inspirational leaders. However agile principles do encourage a particular form of servant leadership, empowering the team to take responsibility and make timely decisions. |
Of course most of the things I've cited as agile mitigations can be applied in any project methodology, including waterfall. It's just that they are more the norm and explicitly emphasised in agile principles and practices, which is something I really like.
Most of all, agile principles help enormously with visibility, collaboration and engagement. This can transform the levels of trust and teamwork between the product team and its key stakeholders. The consequence of this is enhanced satisfaction, due to a much greater understanding of the commitment and expertise of the team, and the issues and risks they face. If failure, by definition, is a problem of not meeting expectations, you're half way there when you adopt an agile approach.
However, all this, in the end, ultimately still relies heavily on the skills of the team. Just because agile methods state these principles and have some inherent risk management built within the process, it doesn't mean the team necessarily has all the skills and experience it needs to execute the princples consistently.
See also:
Most IT Projects fail. Will yours?
DIY Guide for Fixing a Failing Project - by Mike Cohn
10 Key Principles of Agile Software Development
10 Good Reasons to do Agile Software Development
0 comments
CNN: "Agile Development Is Transforming Business"
CNN has compiled a list of the 50 people, products, trends, and ideas that are transforming the world of business. Agile Software Development ranks #18.
"It started as a rebellion against overwrought, Dilbert-style software development projects. Today the set of practices known as agile software development is reshaping the way coders and entrepreneurs create Web-based services. Agile teams work very quickly -- sometimes in as little as a week -- to create small chunks of code. Once a component is finished, additional features are added, with the process repeating indefinitely. Agile also has a reputation for enabling managers to deliver products on time and under budget, which helps explain why it has become a methodology of choice at companies like Google and Lockheed Martin."
50 Who/What Matters in Business, according to CNN
4 comments
"Agile is a Hoax" - Does That Make Me An Alien?
I can't believe it.
There I was, happily practicing agile principles. Enjoying a wide variety of very clear benefits as a direct result of implementing Scrum.
Then along came 'Anonymous' and commented on my blog...
According to Anonymous, "Agile is a Hoax".
At first I was offended. I didn't like being called a Hoaxer. I thought I should remove the comment from my blog at once.
And then I thought it through...
What is the intellectual capacity of a person who writes a comment like this?
Please don't get me wrong...
I don't think agile development is the answer to world poverty.
I don't even think it's the answer to all software development projects in all scenarios.
However I do think it has a lot of advantages to offer when the circumstances are right.
Anonymous didn't even have the courtesy to leave their name.
Anonymous didn't say "I don't like Agile because...", or "I've found Agile doesn't work because...", or "I prefer waterfall because...".
No, none of that.
Anonymous just said "Agile is a Hoax".
To me, this is like a sulky school kid kicking the ball away when losing a game of football. Or throwing their toys when losing a game.
So I decided to leave the comment as it is. I decided to treat it with the contempt it deserves. And perhaps to see how others respond to it.
On the other hand, I've probably given it too much credit already, by writing this post :-)
To see the original article that inspired Anonymous to share their wisdom with us, click here: "10 good reasons to do Agile Development".
8 comments
10 Good Reasons To Do Agile Development
Here are 10 good reasons to apply agile development principles and practices...
1. Revenue
The iterative nature of agile development means features are delivered incrementally, enabling some benefits to be realised early as the product continues to develop.
2. Speed-to-market
Research suggests about 80% of all market leaders were first to market. As well as the higher revenue from incremental delivery, agile development philosophy also supports the notion of early and regular releases, and 'perpetual beta'.
3. Quality
A key principle of agile development is that testing is integrated throughout the lifecycle, enabling regular inspection of the working product as it develops. This allows the product owner to make adjustments if necessary and gives the product team early sight of any quality issues.
4. Visibility
Agile development principles encourage active 'user' involvement throughout the product's development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project's progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.
5. Risk Management
Small incremental releases made visible to the product owner and product team through its development help to identify any issues early and make it easier to respond to change. The clear visibility in agile development helps to ensure that any necessary decisions can be taken at the earliest possible opportunity, while there's still time to make a material difference to the outcome.
6. Flexibility / Agility
In traditional development projects, we write a big spec up-front and then tell business owners how expensive it is to change anything, particularly as the project goes on. In fear of scope creep and a never-ending project, we resist changes and put people through a change control committee to keep them to the essential minimum. Agile development principles are different. In agile development, change is accepted. In fact, it's expected. Because the one thing that's certain in life is change. Instead the timescale is fixed and requirements emerge and evolve as the product is developed. Of course for this to work, it's imperative to have an actively involved stakeholder who understands this concept and makes the necessary trade-off decisions, trading existing scope for new.
7. Cost Control
The above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost.
8. Business Engagement/Customer Satisfaction
The active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, create much better business engagement and customer satisfaction. This is an important benefit that can create much more positive and enduring working relationships.
9. Right Product
Above all other points, the ability for agile development requirements to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the team build the right product. It's all too common in more traditional projects to deliver a "successful" project in IT terms and find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is absolutely on building the right product.
10. More Enjoyable!
The active involvement, cooperation and collaboration make agile development teams a much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops. Instead of lengthy status reports, we collaborate around a task-board discussing progress. Instead of long project plans and change management committees, we discuss what's right for the product and project and the team is empowered to make decisions. In my experience this makes it a much more rewarding approach for everyone. In turn this helps to create highly motivated, high performance teams that are highly cooperative.
Implications of embracing agile development principles
But there are implications. There's no such thing as a free lunch! And there's no magic bullet for software development. Sorry, no, you can't just drink the cool aid :-) In exchange for all these benefits, you do get less predictability, software and humans are still difficult, you can't blame someone else if things don't go right, and it generally requires much more commitment and effort from everyone involved - i.e. teamwork is even more important.
Nevertheless, the advantages of agile development are really compelling.
13 comments
