Question from one of our teams:

• Team plans for 50pts in the Sprint.
• A new priority comes to the team, team agrees to take it on, say it’s another 5 pts believing they can do that plus everything else that was planned.
• The team completes the original 50pts, plus the extra 5.
• At the end of the Sprint, what’s the % delivered? 55 Completed / 50 Planned = 110%?

Answer:

When the team is evaluating additional working flying into the team, it’s a collective decision to take it on, and because we want predictability and potentially shippable Sprints, we don’t want to take on more work if it’ll compromise not completing others.

Thus, if the team does decide to take on another 5 points, they’re increasing the commitment to 55 (in this case). Therefore at the end, if they complete all 55, their % delivered is 100%.

We’ve been progressing on our journey towards a higher degree of Agile, and the tool that we’ve been using historically is Microsoft TFS (currently upgraded to version 2017 Update 2). We have a multitude of teams that work on the same product, for the same release, but on different projects/features. Sometimes a team will be working on multiple releases (that are at different stages in their life cycle), or a project (if it’s big enough) may involve multiple (Scrum) teams.

TFS, from an Agile perspective, has been challenging to adapt. So with a very large initiative that we have under way, for a multi-team effort, the team took the approach of Area Path=\Project X, with Iteration Paths = \Project X\Sprint Y. Which led to some confusion in that it seems duplicative in that if you want to measure the project burn down, if all work items are under the Project X iteration path, why bother setting and querying off the Area Path as well.

Continue reading

At many companies decisions and prioritization tends to be done by committees, in fact Agile itself tends to be very committee driven (the team estimates together, the team determines how things will get done, etc…).

But the Product Owner (or Product Manager in traditional terms) is the key person who’s accountable for the results. They prioritize the projects and features, define desired outcomes, ensure profitability, and accept/reject results.

In the real world many people may have a stake in projects as they are either sponsoring the project, supporting the project, or are affected by the project. So as a Product Owner you will have to interface with stakeholders and sponsors to get their feedback, issues, goals, etc…

Likewise, a Project Manager/ScrumMaster might encounter similar situations where they are trying to garner consensus and agreement.

The problem however is that large committees rarely are capable of making decisions.

[box] Once you’ve got 7 people in a decision-making group, each additional member reduces decision effectiveness by 10%, according to Marcia W. Blenko, Michael C. Mankins, and Paul Rogers, authors of Decide & Deliver: 5 Steps to Breakthrough Performance in Your Organization. Thus, a group of 17 or more rarely makes any decisions.[/box]

Tips:

• Hold a series of smaller sessions (e.g. instead of one 10 person meeting, have two separate 5 person meetings).
• Pre-meet in advance with individuals to gather their feedback, stance, concerns, requirements to that you can factor that in and further prepare for the main meeting.
• Instead of starting with a blank slate and trying to work with the committee to collaborative decide/plan/prioritize/etc… gather initial data and create a good starting point – e.g. a draft plan, and then let people argue/discuss over it.
• Always make sure your management supports where you want to go so that they back you up behind the scenes.

Michael Wolfe on Quora posted an amazing analogy explaining why software development estimates are routinely way off, which results in developers padding their estimates to factor in the fudge of such inaccuracies.

Another thesis I’ve been pondering over lately are the terms “Software Engineering” and “Computer Science”, which imply that software development is purely scientific and engineering in nature. Most colleges run those programs out of their science or engineering departments, and the business surrounding technology (budgets, management, and processes) is premised on the assumption that coding is engineering in that it’s scientific, mathematical, calculate-able, and algorithmic.

All of that is a component for sure – but the process itself, the act of coding is much closer to art. You start off with an idea of what you need to do and how you’re going to do it, you start roughly putting it together, you realize later how things will really need to be put together so you make alterations/refactor, you get feedback from QA testers/analysts/focus groups, and continually refine until you get the final product.

So unless you’re solving the exact same problem every time, what exactly are we basing the effort on? If a carpet guy knows he can carpet a 2 bedroom house in a day, he can be very close with an estimate on a 4 bedroom house. And overtime, the variation of houses is fairly limited.

However, every software project is a new problem; why would the business ask to solve the same problem twice? So we’re estimating based off of as-similar projects done in the past, but unless it is purely a CRUD with zero rules, it’s unique.

Of course an estimate will always be an estimate. But plans & dates get created, promises are made around those estimates, and the estimates become commitments. Which then causes developers to factor in some fudge knowing that the estimate will become a commitment.

Would it help if we get rid of the word estimate and label that value for what it really is, the guess? Imagine updating all your change tracking, ticketing systems, and project management tools to replace the “Estimate” field with the term “Guess”? It would help manage some expectations as to what that number really represents.

The flip side

The problem on the flip side is that businesses are run by plans. They’re not designed to function off of guesses. For example Apple has to gets the contracts signed and dates sealed for the Apple WWDC, payments have to be made to Moscone, Moscone has to prep the building, Apple has to build their booths, sign up all the exhibitors, attendees, etc… so whatever software is planned to be presented has to be ready to roll by then.

It’s a fascinating challenge, and here are some thoughts.

1. Break down the problem into a collection of micro-small problems.
• Smaller problems are easier to size, internalize, and visualize. Many Agile based processes employ this in the form of small as possible user stories.
2. Get formulaic about it.
• If a team consistently applies a 2X b.s. factor, and is 80% accurate – you then have variables to build a formula & pattern around it where you project a target date -/+ x% based on the accuracy, and then build in risk mitigation strategies to make sure you’re managing the risk of not being accurate.
3. Prioritize & focus.
• A good practice at any level (from executive to individual contributor) at any thing (business, coding, personal life).
• Make sure you focus on achieving at least the top priority in it’s entirety by the target date instead of having advanced multiple priorities but never fully completing any. One thing done is better then 10 things almost-done, because almost-done is the same at not done.

The purpose of the daily stand up meeting in Scrum is for the team to synchronize with each other. The standard format is to time box the exercise to 10 or 15 minutes at a fixed time daily to ensure it happens, and happens quickly by not allowing people to sit down and get comfortable.

It’s organized by the Scrum Master, and each team member briefly recaps:

1. What they worked on yesterday
2. What they’re working on today
3. Any blocking issues

One of our teams that is undergoing the transformation towards Scrum came across an interesting situation:

• A Sprint, and all its stories have completed all development, testing, acceptance, sign-off, product owner acceptance, etc…
• One Story in the Sprint cannot be released with the Release – because there’s a dependency on the business to have completed end-user training, which the business needs a few more weeks to do.

So how would you handle this?

• Approach 1: Story does not meet the definition of done.
• The training item should have been a task for the story in order to satisfy the goal of potentially shippable.
• Since a dependency/condition to being shippable was not met, it’s not done.
• Thus the Story would be pulled out of the Sprint and moved back into the backlog or into the next Sprint if it still has value and released on the next Release.
• It would cause a dip in points and artificially drop the velocity for that Sprint (all the work by the team was satisfied, there’s no more work to do), but that dip is ok as it points out an issue that prevented value from being delivered.

• Approach 2: Business issues should not affect velocity. 
• The team completed all work needed to create releasable code – the velocity should be recognized.
• If you keep the Story in the Sprint, it would delay the Release… for weeks. Which is the prerogative of the business. However it’s not a few days of delay, it would bump up against the timing of the subsequent release which goes against the mantra of continuous value… value is not created until you release it.
• Alternatively, you could ‘complete’ the story to record the velocity, but create a placeholder in another Sprint to recognize it actually being released. Or replace a faux/filler story just for velocity tracking purposes, and move the real story into the real Sprint/Release that it’ll get released in.

VersionOne, one of the juggernauts on the Agile tool industry, is prepping to launch a total overhaul of their user interface. And judging by the teaser images, it looks like a big leap in the right direction.

Last year we at Amcom Technology had evaluated a number of Agile tools, including V1. Our thoughts at the time were that it was incredibly feature laden which would suit a very mature agile shop, and our team was relatively new to Agile and the UI just felt too heavy as we wouldn’t use many of those advanced features (and thus not worth paying for something we wouldn’t use).

What I’m hoping to see in this new UI is a better balance towards those who want to keep the process simple, lightweight, and fast.

New Features

Some key new features they’re touting in the next release:

1. Menu enhancements / faster navigation
2. Readability improvements
3. Whiteboard improvements
4. Switch from pop-ups to modals windows (presumably jQuery style)
5. Better search abilities
6. Modernized/Cleaner UI
7. FireFox 5 & IE9 support
8. HP Quality center 11 integration
9. Electric Cloud Integration
10. Git Integration
11. Hooks to their Data Mart/Analytics for B.I

Release Webinar

If you’re interesting in finding out more they have a few webinars scheduled which you can sign-up from here.

Earlier this year (Jan 2011) there was a lot of hoopla over an article by Scott Ambler on Dr. Dobbs Journal asking Certified ScrumMaster’s to denounce their CSM.

Scott writes:

1. My hope is that all Certified ScrumMasters (CSMs) will denounce the CSM designation if they haven’t done so already. You attended a workshop; it’s nothing to brag about. Also, if you work for an organization that still wants their agile staff to have the CSM designation then you should help ensure that whoever is inflicting that constraint fully understands what it takes to “earn” the CSM.
2. My belief is that the Certified Scrum Trainers (CSTs), and the Scrum Alliance in general, can do a lot better. In reality, you’re the ones who need to denounce the CSM scheme and to declare it over.
3. I’m impressed with the recently formed International Consortium for Agile (ICAgile)and their strategy surrounding agile certification. They appear to be on the right track and my hope is that they find a way to stay on it. Anyone offering agile training services should consider looking into this.
4. Finally, I’ve said it before and I’ll say it again — The Scrum community, and to a lesser extent the agile community in general, has embarrassed itself by tolerating the CSM scheme. Enough is enough. We can do better, and until we do so, our integrity debt continues to grow.

At a surface level this did make sense. During this time I was also putting together a training proposal to help ramp up the various teams at my company who are involved in software development projects, and was very disappointed when I found out how easy it was to get the CSM (two day workshop with a guaranteed pass on the test).

The heart of our training program consisted of onsite training by cPrime that involved all developers, business analysts, and product owners. It was very practical, intense, and hands-on as we worked through the mechanics of the process.

A secondary aspect to that training strategy was to have two people get their CSMs – so that we have least some people on the team that have a deeper understanding and could help lead the transformation. Hence the disappointment when we found out how little is involved to get a CSM.

One of the managers did the CSM ahead of the onsite company training, and I did mine after due to a scheduling conflict. I didn’t think I’d learn much more than what we had learned from the hands-on training. But I found it actually very beneficial.

You need to start somewhere

If you’re getting into Scrum, you need to start somewhere. The CSM training, at least in my case, went into the deep understanding of why we do these various practices, organizational behavior, leading change, and even human psychology. I wish I had taken my laptop because on top of the slides I was writing as fast I could as the trainer dove into various topics, and I ended up with 10 pages of handwritten notes.

Hiring implications

On the hiring side of things, there’s been an explosion of agile related activity. I’m sure there are companies that want to get into agile, and aren’t quite sure how to filter for the top candidates. So filtering for the CSM designation would be an easy first step to try.

However as a manager of a web development team, when hiring you try to gather as many elements/clue/pieces to a person’s profile as possible as it is a big decision to hire someone. The CSM to me doesn’t say they’re an expert, but rather that they at least have that formal theory as a foundation.

Our team had been self learning agile for months, and we felt fairly confident in all the dots, but the CSM training course helped connect the dots together in order to see the big picture – as well as multiple angles of that 3D picture (i.e. seeing things from the various perspectives of different people).

As a hiring manager what I’d also look into, if someone has a CSM, is where they got it from and who the trainer was and research them. Having experienced four agile trainers training our company at different times, we found the trainer/coach makes a huge difference.

At the time, the denouncing-CSM-movement did make sense (to me) on a surface level – if a 5 year old can take the course and get a CSM… it’s worthless. However on a deeper level it serves as a starting point, that you’ve been formally presented with how all the dots fit together, and ideally that you care enough about the cause to begin immersing yourself in the theory.

But it’s only a start – if you were to interview with me, I’d then want to see how you applied that theory, lead change, and helped an organization maximize it’s value in I.T.

Blessing the CSM

The story I heard was that when the Scrum Alliance was initially formed back in the day, they never intended the CSM certification to carry any real importance – it was really just a merit badge to indicate that you cared to learn about this stuff (and Scrum in its fledgeling years didn’t have that many CSMs). But it exploded faster and bigger than what they had ever anticipated, and now that it’s becoming main stream, the validity of the CSM is now under scrutiny.

So yes, with Scrum becoming mainstream, the Scrum Alliance absolutely needs to start working on creditability and making sure the industry doesn’t get tarnished as a result of credential dilution.

Having said that, whomever has a CSM, I hope you don’t denounce it. I hope that you take it seriously as a badge of your conviction towards making customers happy, maximizing value, creating openness and transparency, and working with product owners, and management to create positive work environments (which then yield high producing teams).

I hope that as a CSM you are humble enough to recognize that a CSM is just a start, and that you’ll immerse yourself in the spirit and iterative perfection of its practices.

Our company HR/Finance Exec had heard about the Agile transformation we’re currently undergoing, and tomorrow we’re doing a company BBQ – so jokingly she asked:

Does agile mean we will release the food as it is cooked?

So I thought I’d take a lighthearted stab at explaining the Agile/Scrum approach if it were to be applied to a BBQ. To keep it digestible to someone who is unfamiliar with s/w development I kept is simple by omitting things like the various meetings (planning, retrospective, and scrum meetings), various roles, that the Sprints are equal length, that you probably wouldn’t map out in detail that many Sprints, etc…

The core theme was the prioritization aspect of it, and that the Product Owner has a goal or desired outcome with each Sprint.

Response:

The team that’s committing to the work agrees to what they’ll deliver in fixed time increments.

Product Vision: For everyone to gather together, socialize while eating BBQ’d burgers and hot dogs, and feel a heighted sense of unity.

Release 1: 06/14/11. Release goal: to eat hot dogs and burgers

Sprint 1: (the day prior) 5pm – 8pm

• Priority 1: Get meat
• Priority 2: Get buns
• Priority 3: Get salad
• Priority 4: Get snacks
• Priority 5: Get drinks

Sprint 2: 11:00am – 11:30am

• Priority 1: Burger Stuff –  Chop up tomatoes, lettuce, onions
• Priority 2: Marinade anything that needs marinating
• Priority 3: Prep salad

Sprint 3: 11:30am – 12:00pm

• Priority 1: Light BBQ
• Priority 2: Begin cooking meat
• Priority 3: Set up tables
• Priority 4: Deploy salad
• Priority 5: Deploy snacks
• Priority 6: Deploy drinks

Sprint 4: 12:00pm – 01:00pm

• Priority 1: Serve food
• Priority 2: Consume food

Sprint 5: 01:00pm – 01:30pm

• Priority 1: Clean up BBQ grill
• Priority 2: Dispose of trash
• Priority 3: Put everything away
• Priority 4: Lie down on floor from feeling too full

Each Sprint focuses on the next bucket of the most valuable priorities, in that if they’re not done, the lower priority items aren’t of much value (e.g. in sprint 1, there’s no point in getting drinks if there’s not going to be any meat because that’s a stated objective in the vision).

The person deciding the priorities is the Product Owner. After each Sprint, they’d be re-prioritizing what goes into the next Sprint based on the throughput data they gathered in the prior Sprint. Anything that didn’t get done, could go back into an unprioritized bucket, or moved into the next Sprint if that’s one of the next most valuable things.

Scenario: At the end of Sprint 2, prepping the salad priority didn’t complete for whatever reason.

Example reprioritization decision 1:

• The Product Owner can decide that we have to keep moving forward as cooked meat directly supports the product vision, not salad. Salad’s a lower nice-to-have priority. Burgers and Hotdogs deliver maximum value so we can’t compromise that user experience.

Example reprioritization decision 2:

• The Product Owner could decide that you can’t have a BBQ without a salad. So going into Sprint 3, the Product Owner may re-prioritize by moving the prepping of the salad into there, and pulling out snacks and drinks (salad = healthy, healthy customers are better for profitability).

The Product Owner is empowered with enough authority to make these priority decisions, however they’d be accountable to the business for the results.

So after the release is complete, the Product Owner would measure if they achieved the heightened sense of unity and use that to strategize on Release #2 (the next company BBQ).

One of the problems with the traditional waterfall method is that it’s predicated on the notion that it’s possible with enough planning and requirements gathering to accurately estimate out the effort of a project.

If that were even possible, and your life depended on it, you wouldn’t feel comfortable until the team has spent an enormous amount of time putting together analysis and various levels of technical design.

In order for that possibility to exist you would have to be aiming for a fixed target, whereas developing software is a moving target where scope can change at an time (agile embraces and expects change).

So after weeks or even months of analysis you drop the bomb on the stakeholders of the project that what was asked for won’t fit the required timeline without a decrease in scope or change another project dimension (capacity, budget, resources, etc…).

Meanwhile, stakeholders want an estimation done immediately. There may be a constraint or deadline that needs to be hit, there may be a funding window to get approval, stakeholders might need time lining up shared resources and don’t want to reserve people if they’re going to end up vegging out on the bench waiting for the project to commence, etc…

So what’s the compromise? Story points!

Story points solve the problem

The problem is we need a quick and easy way to schedule out work. In the waterfall approach the business views estimates as commitments, but estimates are estimates – they’re not actuals. You’ll only ever know the actual once the work is completed.

In waterfall land your plan relies on as accurate as possible estimates because you build out your timeline based on that. With agile, your work is based off of fixed-length time boxes – so you know how long each iteration is going to be, the only question is what you fit inside each of those fixed sized buckets of time.

So imagine you’re filling up boxes with various household items, do you really need to know down to millimeter accuracy how big each object is in order to have a sense of how much you can fit in a box? More importantly would it be worth it to spend 2 weeks cataloging all your household items into Excel using a measuring tape in order to make a plan that fills each box to it’s maximum capacity – or is there more value in spending that time to just start filling the boxes by eyeballing roughly what will fit?

I know that some things are twice as big as others, I may not know their exact dimensions but I can guestimate that I can probably fit:

• 10 small things
• 5 small things, and 2 big things
• 4 small things, 2 medium things, and 1 big thing

In this case I’m working on filling a box, but on another project I could be working on buildings and I may not even need to change my point system much.

My buildings might fit into a 1 (small) to 5 (really big) range of categorization. The nice thing about using points is you get away from using time to estimate size. In theory you could use hours, such as 1hr for small things, 5hrs for medium, and 10hrs for large. But the problem is that when you start talking hours people start assuming you’re talking about duration or effort, so it’s best to use points or any term that signifies size.

Story points converted to time

These numbers initially can’t be converted into time, you have no data in order to base such a conversion on. But as you perform iterations over time you’ll be able to track how many story points are completed with each iteration and thus know what your velocity is. Knowing that an iteration was 60 man hours, and it was 6 story points, you could formulate that a story point is about 10hrs of effort.

Knowing actual hours might be an interesting tidbit, but one could argue they’re irrelevant. This is because when you’re planning out your next iteration you’re still using the story point technique to fill your boxes, but now you have historical data to improve your understanding of how many points fit into a box.

Recap

• Estimates are estimates, not actuals.
• Actuals are historical, you can never know them upfront.
• No developer in their right mind would commit to an estimate without heavy duty specs.
• Waterfall requires time consuming analysis in order to get specifications detailed enough for someone to commit effort and duration to. Knowing effort, waterfall then plans out the timeline.
• Agile is fixed-length timelines. You already know when an iteration/phase/sprint ends. You just need to fill up those iterations with work.
• Story points are a quick way to estimate out the relative size of one feature vs. another feature. Size is the keyword (vs. effort or duration).
• Using relative sizes, you’ll have a rough idea of how many points can be completed within an iteration.
• As iterations end, you’ll have a stronger understanding of how many points an iteration can fit.