Many software development teams work in an environment where they are beholden to date-driven releases. And many of these same teams aspire to be “agile”. Agile means a lot of things to a lot of people, but at it’s core it’s about only releasing things that are DONE. What drove the whole Agile movement in software was that the waterfall process of days of yore could drag projects on for years without anything being released, because the standard of DONE was essentially unachievable. Either the feature functionality was not complete, the testing was not complete (or do-able), or late-breaking integration or release issues were discovered which impacted the scope.
So what’s a team to do when they are told “You shall ship on this day, with this product“?
I have had to deal with this situation for most of my stint as a developer. This post is intended to share some of the best practices I’ve garnered from the projects I’ve worked on that are of this ilk.
Lose the Religion
projects in tiny slices is something you should be able to do, like driving on ice, not something you should always do, like driving on ice
— Kent Beck (@KentBeck) March 11, 2013
Driving on ice simply requires the right training and equipment. It’s a calculated and deliberate process but can be safe. And if the road is made of ice, it’s all you can do.
Figure out your time constraints – map out your start and end dates. Working backwards from the drop dead ship date – create a two week buffer at the end. Everything in between is available for iterations. First iteration is called Iteration 0 – this is to tackle is high risk items and discover the lay of the land. You should come out of this with your technology and architecture choices. Try to keep it to a week. The product owner needs to be very alert during this phase as the team members report back every day on how they are doing in the discovery and design phase. This is where you get your first warning signals if something is going to be harder than it looked. Your team may have to do proof of concepts and compare options. Make it clear they are going to be making critical design choices that have to solve the customer problem, but also be feasible in the constraints you have.
Plan the first 2 iterations at the end of this.
Subsequent iterations should be relatively short (2 weeks?), fit as many as you can in between Iteration 0 and your buffer.
Stop to demo, course correct and plan the next iteration as usual within the cadence of the iterations. Celebrate the little victories, and obstacles overcome.
Don’t Over Track
Keep track of what you need to do, who is doing it, and what got done. Get things sequenced in logical order (not just priority – some infrastructural stories might come before the top Product priority because they are enabling stories). Tracking is very important for QA purposes (they need to get ahead of the development if they can) and not important for velocity stats – remember a death march is not worth tracking for metrics – it’s worth tracking for what is being done, that’s all.
Embed Your Customers & Product Owners
One of the principles of agile development is transparency. Some mechanisms are built into most agile processes to promote that, namely the daily standup, iteration demos/reviews, and in some cases pair programming and daily test suite reports. These all keep the team up to speed on the status of the project, however it’s the product owner who ultimately has to do something with this data.
Embed your product owner, be it a Product Manager, a Customer or a stakeholder in the outcome of the project. By embed I mean physically embed them with the team, right in the middle of the action, co-located (Yahoo! style). The product owner benefits by hearing the chatter of the team beyond the scheduled meetings, and the team benefits from the availability to answer questions on requirement refinements, tradeoffs in implementation etc…
The knowledge the product owner has on a day-to-day basis gives them what they need to make course corrections, set expectations with other stakeholders, and also get a sense of what obstacles they can help clear in advance of work in that area.
Ensure Designers are Pigs, Not Chickens
Assuming the designers are embedded as I prescribed, they will quickly see the progress the team makes with their designs, or not. The critical dynamic here is that there’s a tight feedback loop between the implementation and the design. It’s ideal if a designer can sling some HTML/CSS in a web project, for example – that let’s them get ahead of the team and set up templates and patterns in advance. When designers are committing code, they have skin in the game, and join the implementation team. Designers should also be ready to offer more than one option to the team when push comes to shove – some designs are better, but sometimes they are harder to pull off – a good designer will appreciate constraints, and come up with something still usable and aesthetic, but easier to build and test.
Empower Your Team Members
The term product owner can sometimes disenfranchise some team members as it gives them the impression that they don’t have skin in the game. Make it clear that the “owner” is simply the person appointed by the business to make decisions in scope based on the resources and time. They should be the experts in the domain your team is working on and know what can be traded off when the time comes. It’s up to the team members to bring issues to the forefront and present options to the owner. The only way to encourage ownership of the outcome in some contexts is to put it in practice. Find opportunities in the standup to tease out opportunities for team members to contribute their ideas (in the parking lot of course) and incorporate them into the plan. This cycle creates a series of celebrated contributions to the outcome that keep the team invested.
Get it out there, there will be bugs, there will be compromises. Deliver the value to your customers, celebrate it, be proud of it, and you will feel all the more inspired to go back and make it even better.