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

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.