What the business expects from agile

8. Expectation #1.1 Traceability: o Long-term Plan o Business Strategy/ Priorities o Target Outcomes o Short Term Plans o Project Goals o Project Objectives o Iteration Objectives o User Stories o Tested Code

10. Business needs to know how to envision at a high level. Think in terms of business outcome and not product attributes.

11.

12. Planning Example(omitted/ confidential - sorry)

13. Expectation #4 Change is not the norm.

14. Expectation #4.1 Change needs to be controlled

15. Expectation #5 Regular, honest communication with an eye toward problem solving

16. Expectation #6 Make it real before you make it right. Right product --> right way --> nice buttons

17. Expectation #6.1 Do the simplest (smallest) thing possible to meet the requirements in front of you. REF: Kano Model: http://en.wikipedia.org/wiki/Kano_model

18. Convergence "Working software" - is the objective of the development team at the end of an iteration. “Business value” is the objective of the business. Ourgoal is to make these two things the same.

19. SUMMARY

Notas del editor

For every problem, there is a simple solution – one that will address 80% of the problem anyway. This is not new. This is not difficult. Some of what I’ll tell you is pretty straightforward stuff. But if it’s so easy, why are so many organizations not doing it? So I won’t spend a lot of time on some of those basic principles, but I’ll mention them to invite discussion on why we don’t do them or what to do when it’s out of our control.I'm hoping by packaging it the way I have and inviting dialog, that you can identify where your own organization is, and zero in on one or two things that you can try to change to improve the way you work. This works for *me* - it may not work for you - but let's talk about that along the way.
Obviously…(?) the business needs to have & drive a set of priorities. Q :What’s the difference between goals and objectives?The goal is to make money (market share, ROI, etc) . The objective is (may be) working software. So #1 – learn the business goals. (business drivers) What are your company’s Vision, Mission, Strategic Priorities, Roadmap? If you’re not willing to get involved at that level, you are accepting your role as one who just does as he’s told.
Develop from backlog according to current priorityWork until … Done? Done = ?But:How do you plan anything long-term? How can the business make commitments to stakeholders? How can the business market and build sales under this premise?(BTW: The business doesn't care what development methodology is used or what it's called. The business cares that expectations are set & met.)
I’m going to give a list of expectations – some from the business side, some from the development side .. As I cover these, think about how they apply or whether they apply to your organization. And before I go on to the next expectation, stop me if I haven’t asked for you to challenge the expectation or provide an example of how it does or doesn’t work for you. We’ll note those challenges and discuss them at the end.Also, there is a difference between companies that create software as a business –vs- companies that create software to support their business.
Forget Agile for a moment ….The business needs to know what its roadmap is and what its priorities are.That is – not just user stories, but major initiatives.Not everything is #1. I won't go into decision making on how to select and prioritize initiatives for a portfolio – there are multiple methods for that, but OK, you can make $20billion over here or you can make $20 billion over there, risk level is the same for both - well unless you're resourced to do both, you gotta pick one as #1. A bird in the hand…. *important point - EVERYTHING gets prioritized somewhere down the line - so if it isn't prioritized at the top, it's prioritized at the bottom by the people doing the work, just by nature of what they choose to work on on any given day. So better to have one view of the #1 priority coming from the top than to have 600 views of priority #1 emanating from the bottom.
However .. your organization may not be at a place where you are planning ahead 10 years, 5 years, or even 1 year .. (you ought to be able to plan a year out, but maybe you can only plan out a quarter..( the farther down the list you are here in ability to plan ahead, the harder it is to be successful, because you're not just trying to hit a moving target, you're not even sure what the prize is for hitting it.No challenges to this. This is fact. If your organization is not doing this, software methodology isn’t the biggest problem, and the best you can do is mitigate the chaos.– any thoughts concerning this that you’d like to discuss later?
The question changes from "Can you deliver X functionality by Y date?" to “We need to deliver *something* by Y date – approximately how refined will it be?" Continued refinement goes into general backlog & is prioritized with all other enhancements, etc.. So while some agile practitioners say "iterate until it's done & release it when it's ready" the business needs something more concrete than that. (( Over time, it's possible to build a level of trust and assurance of velocity that can make the business less date-driven. )) But sure as you’re breathing, the date will occur - and development will have produced *something*. So will it be a sketch of the Mona Lisa or will it be a really intricate painting of a nose? The deal that dev and business need to make is that the product functionality may be lightweight as of a certain date. It's not that the product won't be there. (Again, this depends on upfront collaboration, high-level scope & estimates and mutual trust between bus & dev.) Estimates – Especially at a high level, you may be wrong in your estimates. That’s OK – it has to be. You can use 3-point estimating, Delphi method, Planning Game, etc to produce the best possible estimates along with a degree of confidence in those estimates. .. But you have to be able to give a reasonable estimate based on what you know at the time.Presuming a challenge of “but how?” … I will show an example of how to do this in a few slidesOther challenges to this?
Presuming again a challenge of “but how?” … I will show an example of how to do this on the next slideOther challenges to this?
Generic vs specific SizingPriorityResourcing by Quarter
In some businesses, change occurs more often than in others. For the vast majority, that really isn't the case. Startups with competition that's announcing new products daily, banking/finance or healthcare where regulation/announcements of regulation mean competition is more reactive than planned - there will be more change. But even then, there is still a level of certainty that needs to exist – The business needs to have a plan and needs to follow that plan .. Again, trying to hit a moving target – it isn’t just hard to hit the target – is it actually the *Same* target, or is your organization shooting at whatever it sees?Or (next slide…)Problems with this?
Kneejerk reactions kill productivity. Not that you shouldn't be able to react to change quickly, but be thoughtful about it. Wrap up what you're doing and plan how you're going to adjust to change. Make sure everyone understands the change. You've heard people say that no one likes change? It isn't change they don't like - it's uncertainty.Problems with this?
After iteration planning:What do you expect to complete in the current iteration? (How does it compare to velocity of other iterations?)What are you going to demo?What do you need from other teams?What do you need from management?What's going to keep you from getting it done?Mid-flightWhat's going to keep you from getting it done?End of iteration:It's done. No excuses - warnings should have been communicated mid-flight.(Sound familiar?) Any reason that we can’t do this?
Show the value to the business early & often.caveat to #6 - depends on the maturity of the product. new products you can be more skeletal in a single iteration - production enhancements, you have to be more complete - but that presumes that the entire system is already in place - so you can define the new features as much smaller units. New products it's better to create the entire structure before refining the parts. Think of the first airplanes - inventors were not concerned with a production-quality seat - in fact, there was none. First, they created something they could get off the ground.Assuming we all buy in to Agile, no problems here, right?So let’s see if there are any problems with 6.1 ….
Fix edge cases in a later iteration. (When you are delivering new functionality/ new product. When doing product maintenance, it may make sense to cover more use cases in a single iteration - though still addressing the top 80% in the first pass, with remaining cases on second pass.) If a story is part of a larger context or design, but that larger context hasn't been defined yet or prioritized yet, don't do it. Simply don't do it. (You can bring to people's attention that the priority might be out of line, knowing that the story will have rework later if we ignore context now, but) until it's prioritized, do the simplest thing possible to finish the story. Business - you're going to see some ugly product because of this - you have to accept that as part of the process. i.e. don't try to put a glossy UI on a product that doesn't have the functional stories completed yet, and don't be bothered that you can't see the pretty, final UI.what if an elephant wants to ride in your plane? Assume it doesn't until the requirement says it does. Yes, that can result in disaster - the business needs to be conscious of those eventualities and how to retrofit - informed prioritization comes into play. But assume priorities are correct, raise concerns, and then do what the requirement says. (but don't be passive aggressive)REF: Kano Model: http://en.wikipedia.org/wiki/Kano_model Someone might argue that when you build a house, you have to know where the bathroom is going to go .. Well, software isn’t a house. Software is virtual, and rework means something different.
Product development is a team-effort. When we fail to deliver, the team fails (and hopefully learns.) We don't blame anyone, but we identify and fix where the process broke down.

What the business expects from agile

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a What the business expects from agile

Similar a What the business expects from agile (20)

Más de Dave Ungar

Más de Dave Ungar (10)

Último

Último (20)

What the business expects from agile

Notas del editor