Now that you know where you fit in an agile world and are maybe convinced that this whole thing is worth a shot, what changes can you expect in your role as manager or business stakeholder?

More Collaboration

Collaboration is always important- it’s how the development team knows what needs to be built. However, in agile, collaboration is even more important, such that anyone on the delivery team should be able to talk to you, the business stakeholders or even the customers at any time to get clarity on any issue. Instead of going through requirements documents or business analysts, collaboration is now more direct and hopefully face to face (although any scope decisions should go through the Product Owner because he owns the backlog.)

More Transparency

Another change is being able to see what is happening, whenever you want to look. You can see what is on the backlog to be built (stack ranked list of things for the team to work on), what they are working on today, and what they’ve delivered in the past.  The stories are in the order of importance, arranged according to value and risk, so you can get a feel for what is going to be developed whenever you want.  Realize the product backlog is constantly being “groomed”, so stories can be changed, moved, added, deleted, or refined at any time.  This is how the project reacts to change.

Another thing agile teams produce is a burndown chart normally used in sprints to show remaining hours of expected work – charted against an ideal burndown line.  This chart gives you an at-a-glance indication of how the sprint is progressing.  It is important to note the burndown is not to be used as a stick with which to beat the team, but rather as an indicator of when something unexpected happens, which allows the team and you to remove roadblocks or react to change.

Less Documentation

Somewhat because of the increased collaboration and transparency as well as the principle of working software over comprehensive documentation, documentation tends to decrease in an agile framework. Instead of defining all the requirements and artifacts needed for the project up front, teams instead define the requirements iteratively though user stories in the backlog, with “just enough” detail to mitigate the risk of getting it wrong. In your company, this may mean a light-weight document up front to get agreement on high-level scope and objectives (perhaps an Agile Requirements Document) and from then on those requirements are in the backlog and managed there.

Approvals and sign-offs are a little different as well, with customer collaboration being valued over contract negotiation. The user stories or requirements are not a contract between customer/business stakeholders and the delivery team on what will be built. Instead, in an agile world, the value management team gives the delivery team a problem to solve and maybe a high level product concept and trusts the team to collaborate with them to determine the best solution and deliver the most valuable things first! There is still a form of approval and sign-off- this is most typically seen at the sprint review, where the PO acting on behalf of the business/customer, either accepts or rejects the user stories as done. Your company can implement other mini-approvals in the process as well, such as at a document stage or when the user stories enter a sprint. Note: these approvals are much less formal than you’re likely used to though- it is not an audit process to beat the team with, but rather a mechanism to ensure that the people needed in the process are in the process.

Different Time Commitments to the Project

All of these changes lead to a different time commitment from the value management team on the project. Instead of an upfront effort to define requirements, a little in the middle to answer questions and a big effort at the end to test, agile is more predictable in its time commitments. You are likely to be involved in every sprint setting the vision (usually early in the project- we don’t want to change the vision every sprint!), giving the team its overarching goals for the product, answering questions and maybe even assisting in User Acceptance Testing (business stakeholders are more likely to do this than management).

Different Metrics/Reporting

Much of what you used to use for tracking success doesn’t apply anymore.  There aren’t work break down structures, or estimating by percent complete or earned value. Instead, first and foremost, you’ll get working software at predictable intervals that you can base what to build next from. Additionally, you’ll get burndown charts (mentioned above), velocity charts (below) and better estimates of percent complete because it won’t be based on phase but based on a given feature/user story and how close it is to being “done, done, done” (done, coding, done testing, done documenting, done everything to deliver to a customer).

Another thing – the roadmap is different now – and probably better than you are used to.   Instead of a fixed scope and date that is guesswork based on past experience, in agile, the teams uses “yesterday’s weather” (how much they have most recently been able to deliver) to determine what they can deliver in a given time frame or how long something will take them to deliver. For example, once a team knows its velocity (how many stories or story points they can deliver in a sprint), they can start to forecast their delivery based on an ideal line at current course and speed and add a cone of uncertainty (probability bands) around that line to give a better confidence interval to their estimates.

With this in place, you can ask a team how much they can deliver by a certain date or when a certain number of feature or stories will be delivered and have greater confidence in their answers because of better forecasting and because everything is “done, done, done” at the end of a sprint.

So, what should you do as a business stakeholder or agile manager? In Part 3 of this blog series- we’ll cover some tips for you to build a great working relationship with your delivery team!