13 lessons from agile projects

Over the years I've had the chance to work on many line-of-business software projects in various roles: developer, project manager, delivery manager, and solution/data/technical architect. This have given me some interesting insights into different flavours of the agile process. Here's my first set of hard-earned lesssons.

One significant caveat before I start: I'm writing about agile in the context of in-house software projects within an enterprise company (capital markets - banking sector). I have limited experience with agile in the context of consultancy projects or building software products. Some of my lessons may still be applicable to agile in different contexts, but caveat emptor - think about your specific context first. 

1. Whatever flavour of agile you use, the team is much more valuable than the process. Complex software projects are ability-led, not process-led. It doesn't matter how good your process is if you aren't blessed with a team strong in domain knowledge and and political/technical skills.
2. You must bring the business with you when you use agile for a specific project  - it should never be just an "IT thing". If the business doesn't buy-in to why you're using agile, then the project will fail.
3. The term "agile" has been overloaded to the point that it's effectively meaningless. So you must understand exactly why you're doing agile in any specific project. The proposed benefits of agile in the context of the current project should be clear to all of the project stakeholders.
4. Adopt agile practices that are project-specific, and linked to the aforementioned benefits. Don't just repeat the same set of agile practices on every project without thinking about the project context.
5. If you're iterating on the business plan, then something has gone terribly wrong. Iteration is for the Elaboration, Construction, and Deployment phases of the project, not the Inception phase.  
6. Don't leave the Elaboration phase without a good understanding of the functional and technical risks. It's tempting to use the agile argument to say that these risks can be revisited at a later stage of the project, when your team has learned more. The problem is that un-surfaced risks can completely wreck your schedule and costs, often at a critical point in the project.
7. Iterate rapidly on both business value and project risk. The "business value" meme is well-known, but it's very important that your team maintains a healthy tension between delivering business value and reducing technical and functional risk. It doesn't make sense to deliver business value at the cost of major risks being pushed to one side. Those risks will likely crystallise late in the project lifecycle and wreck the cost or schedule of the project. So try to schedule the delivery of high-risk items in early iterations, and focus on delivering "customer value", not just "business value" - a subtle, but important distinction.
8. Agile projects need more management, not less. Senior managers will never cease to demand the same results, but with less time and fewer resources - agile is just the latest manifestation of this trend. So you need really good upward communication, ensuring that senior management sees all of the relevant information, not just the good news.
9. Agile tends to expose significant problems in other parts of the organisation such as infrastructure, governance, business engagement, budgeting, processes, environments, and support. At this point there's often a strong organisational tendency to shoot the messenger rather than deal with those problems.
10. A good rule of thumb is to calculate the iteration length by taking the square-root of the estimated project length. So if your project is estimated to take 4 months, 4 weeks is a good starting point for the iteration length.
11. Make iteration 0 of the Construction phase longer than the remaining iterations. You can't build significant functionality without a certain amount of infrastructure. You have to build a team, assemble the DevOps pipeline, assemble equipment, and so on.
12. You need user stories from every project stakeholder, not just the business end-users. Take the banking sector as an example. As well as engaging with the front-office traders and salespeople, we typically gather user stories from the Operations, Product Control, Compliance, Audit, Technical Support, Technical Risk, Networks, Infrastructure, QA, and DBA teams. 
13. Gather functional and non-functional formal sign-offs at the end of every iteration. This practice focuses the minds of both the project sponsor and the delivery team. And when you're told to revisit certain functionality and business requirements, you have a tool to explain why this will cost more and take longer.