Archive for the ‘agile’ Category

Overwhelmed I’ve been driving organizational change in Scrum implementation for more than a year in two companies, and I’ve reduced the focus of change to 4 steps. And in keeping with Agile principal #10, I won’t be writing a long preamble :-).

1. Effective Scrum Masters

A Scrum Master is a process expert, a coach, a disciplinarian, and great at managing their own time.  If you want to know if a person will be a good SM, look at their Inbox. Is it one or two pages, or is it a hundred pages with thousands of unread messages?

My time management process can be boiled down to just a few principals and techniques:

  • 24 hour response on all emails
  • If it’s read but still in my Inbox, then I have an action to take
  • In meetings, my notes will result in actions: either paper notes with a ☆ star, indicating something to do, or electronic notes that I email to myself
  • Schedule a no-duration appointment so that I am reminded of actions to take

Using this technique, I’ve kept my Inbox clean, my notepads blank, and an expectation with my colleagues that I respond in a timely fashion to questions and requests.

Your Scrum Masters must be effective time managers. They are responsible for coordinating Sprints and ensuring planning gets done correctly. They must track implementation of retrospective items. They need to make sure dependencies are resolved, schedule Sprint Review/Demos far in advance. And they are often doing it for multiple teams, or otherwise doing other project work of some kind.

Your Scrum of Scrums Master must be an expert at this, coaching and keeping watch to ensure the Scrum Masters keep up with the work.

2. Principled Scrum

Organizations are different. Their needs vary. Managers want different types of information, results, and plans. Some people will be all for Scrum, others will resist it. You’ll have Q/A on your teams… or maybe not.

It’s okay – adjust how your organization implements Scrum, vary from the “orthodox” methods — but never compromise on Agile Principles. Your Scrum Masters need to know the Agile Manifesto and the 12 Agile Principles. That way, whenever a change is suggested or challenged, you can check it against Agile. Changes are fine, they’re great, they’re desired and expected: just don’t compromise on Agile or you’ll end up back where you started.

3. Acceptance Criteria is King

Nothing slows a team more than stories that lack good acceptance criteria. For the teams I coach, I have one test I use to see if the acceptance criteria is good:

  • How will you know if the developer did the work correctly?

What, exactly, are you going to do? What will you type/run/examine? Can you actually DO the test, or does it require other steps not in the story?

If you, as a Product Owner, as a Developer, cannot absolutely show that the story is working, by executing the steps in the Acceptance Criteria, then it’s not a Done story, and/or the acceptance criteria is flawed. Here are some flawed acceptance criteria items that I’ve seen get into a Sprint:

  • As a Thing, I get built
  • As a Platform Feature, I get refactored
  • As an Engineer, I researched and documented a design
  • Code is written and reviewed

Your acceptance criteria should be detailed: enough so that a developer can execute it or a tester can run it. Browse to the site, enter login credentials, click on the new feature, shows the new stuff. Without this detail, engineers cannot create good definitions of done and the team cannot estimate the size of the story. And worse: developers and product owners will have meeting after meeting to understand what needs to be Done.

4. Interfacing with other teams

Probably the biggest challenge I’ve seen to date is figuring out how to work with requirements outside of your own Scrum team. Within the team, it’s pretty simple to setup priorities for stories: just get them into the Sprint in the right order. It’s easy to track dependencies on stories: you know every day at the Daily Scrum whether there’s a story or task at risk. But what about between teams – both other Scrum teams and non-Scrum teams?

I call this Dependency Tracking. Or sometimes Dependency Management – something with the word “dependency” in it. Other teams have dependencies on you, and you have dependencies on other teams. Stuff they need to do must get done in time for your Stories, and vice versa.

There are three steps to perfect dependency tracking:

Dates: Every request, every dependency must have an actual date : When will it get resolved? When can you give me a date that it will get resolved? When can you give me a date where you’ll be able to give me a date? Never accept anything other than a solid date. And don’t accept dependency resolution dates too close to the end of your sprint. Aim for the middle.

Tracking Tickets/Tasks: Even when you are given a date, don’t absolutely trust it. Create a tracking task or story that’s due just before the dependency, and put it In-Progress: that way you’ll see it at every Daily Scrum. A tracking task is basically “Make sure that X dependency will be resolved as promised on mm/dd.”

Proactive Communications of Changes: Your team will often be a dependency for other teams: you must make sure that anyone dependent on one of your stories gets notified if you aren’t going to make your committed dates. As a Scrum Master, you need to track which of your stories are dependencies, and when they are expected to be Done. If they aren’t going to be Done by the committed date, inform the stakeholders! Stuff happens, people understand that. Let them know if a ticket will be late, and give them the new date. That way everyone has an opportunity to re-prioritize and ensure their teams aren’t sitting around blocked by your dependency.

Questions? Suggestions? What’s the key to effective Scrum in your organization?

Sprint I’ve been on a few Scrum teams now, the latest with my current Intuit Hosting Engineering (HE) position. HE is doing Scrum well, implementing almost all of it as far as I can tell. I recently took the training to be a certified Scrum Product Owner – one of the three primary Scrum roles. It seems like this is what was missing from the Innovation Lab (iLab) processes we used – the “what came next” part that was always a challenge for us.

In the iLab, we had an unmatched process for discovering innovative solutions for tough problems, and getting quickly to the minimum viable feature set. What was tough was then transitioning that to a business unit for development and launch. Scrum takes care of that part of the process.

Diminishing detail What we needed was a feature set that was described in terms of User Stories, detailed deeply enough for a development team to estimate in terms of relative development time (story points). The User Stories would be more than just the minimum viable, getting us over the hump of disbelief on the part of the business – disbelief that the product had enough features. The “minimum viable” would simply be the highest priority user stories, and the entire set would be in the “backlog” – all of the known user stories in diminishing detail.

The cost/time of development would be established if you already had a Scrum team, but it only takes about three Sprints – 1 to 4 weeks – to establish a baseline “velocity” for a new team. Velocity is a simple measure that indicates how many story points that a team can accomplish in a given sprint.

Trifecta When a team follows Scrum, they can become hyper-productive: teams that quadruple their velocity compared to their first sprint. There’s apparently two simple things that get a team to this measure – a backlog that has very well-defined user stories and an automated build that includes automated testing.

I think there’s a trifecta here that, when combined, would be a simple but effective way to make a successful idea into a successful business: front end innovation (iLab style), with lean startup-mindset prioritizing of user stories, developed by a Scrum team.