The Vulnerable and The Invulnerable


Poetically put.  Essential to #Retrospective success.

Diary of a ScrumMaster

The Vulnerable considered options
The Invulnerable made a plan

The Vulnerable experimented
The Invulnerable stuck to the plan

The Vulnerable were open
The Invulnerable were defensive

The Vulnerable collaborated
The Invulnerable segmented

The Vulnerable listened
The Invulnerable assumed

The Vulnerable learnt
The Invulnerable blamed

The Vulnerable grew
The Invulnerable feared

View original post

Updating Trial Version?


RELEASE 1.1.1

A few more tweaks to Reports and a couple of bug fixes.  Working #Lean and #Agile, we release versions as often as we can to respond to your user comments and needs.  Keep them coming!

Download the latest release from the Microsoft Store.  If you’re running any ScrumMaster version, you should automatically receive an update notice from the App Store (Windows 8.1 users may need to search for it).

Biggest enhancement to version 1.1?  A ScrumMaster demonstration project file to download.  Now you don’t have to build your own project in the trial version before you can see ScrumMaster in action.

Get more for ScrumMaster™
NEW:  Get more for ScrumMaster™, download DEMO project file from here
ScrumMaster Windows 8

Practice Safe Scrum!


Practice safe scrum… or be prepared to live with the consequences!

For some of us, too many ritual Agile meetings have not been a pleasant or productive experience, whether we’ve been running one or standing in one.  The reason is simple:  disrespectful human behaviour.  Late to start.  Off task.  Talking too much.  Not contributing.  Low level discussion of problems.  Attitude.  Egos running wild.  Finger-pointing.  Bad-mouthing of code—without even knowing who wrote it.  The list goes on.

There are many good ideas out there that get us closer to scrum ritual happiness, as in the example that follows.  (We pass along those we find as ‘Real Scrum Advice’ posts.)

Education has known for a long time it can give Business some pointers on proven techniques to modify and manage how any team functions—kids or adults.  Unfortunately, Business tends to think it knows all (or at least, Education knows a whole lot less).

Steve Peha’s interview with InfoQ was very interesting.  Not only did he talk about how Agile and scrum approaches can work in the classroom, but he also opens the door to insights for improving Agile adult work environments.  Because even in small teams where everyone basically gets along and works well together, implementing his key points reinforces positive team dynamics.

Why practice ‘safe scrum’?  Because the benefits of the ‘virtuous’ Agile cycle that results are tangible for the team, and they multiply.  Stress is reduced.  Confidence increases.  Collaborative problem solving improves results.  Productivity goes up.  People LIKE coming to work and they are HAPPIER.  The benefits extend all the way to the product end users, as the joy of work well done can transform the project.

“If we get past all of those fears to a place where we communicate more freely and more openly about what we do and don’t know, we can dramatically increase learning and remove the friction that often builds up when perhaps two people disagree and they let that disagreement just fester for day after day after day and sprint after sprint after sprint.”

Sound familiar?  How do you lead a team to improve working conditions, especially if the team doesn’t have a formal leader?  What if the team’s current cultural norms not only don’t support personal or professional ‘safety’, what if it functionally does the opposite?  Under the guise of ‘witty fun’ or other one-upsmanship power games, when barnyard politics rule, the resulting hierarchy doesn’t optimize team results.

Anyone can make a difference.  To begin, lead by example.  A well-timed candid observation to the group can be a catalyst for real discussion.  Team members talk one-on-one all the time, so there’s an opportunity to move gossip into something more productive… organize behind the scenes and then bring specific issues with suggested solutions it to the larger group.  Kick off a discussion of group norms.

Education folks might think in terms of:

#1  The Safety Message.  (verbally stated as a group norm and we all ‘walk the talk’)

  1. “Nobody will put you down or call you stupid.”  (to your face or behind your back)
  2. “There are no dumb questions.  Ask.”  (because somebody else probably has the same question and is reluctant to speak up)
  3. “Brainstorming Rules apply!”  (Have an idea?  Put it out there for discussion, NO JUDGEMENT on YOU, we just analyze the idea.)
  4. KEY:  As Scrum Master, you can say all this at the start of a new project and new team, but it needs to be modelled all the time and reinforced when necessary—by everybody.  Anyone making snarky comments gets called out immediately—by the group, not just by the scrum master.  Respectfully worded, as softly or directly as needed for that person to get the message.  Reinforces the positive for everyone.

#2  Positive team culture.  However you define it.  What is it now?  What would be better?  Is it…

  1. Professional?
  2. Inquisitive?
  3. Evolving?
  4. Customer centric?
  5. Caring?

#3  Structure.  For people and process.  Both need it for the team to function well.

  1. Vision is understood (the Big Picture, Team raison d’etre)
  2. Work is well organized (the bits and pieces, a solid WBS)
  3. Communication is planned (at least some)
  4. Progress is apparent (however measured and monitored)
  5. Success is celebrated (regularly, for real!)

Yes, it’s change management and it’s as complicated as the code you write.  And, it doesn’t happen over night.  Check out Mike Cohn’s comments about initiating Agile process in an organization as the challenges he notes can remain long after the introduction.

And when all is said and done, isn’t it really pretty simple?  It’s about RESPECT.  For other people and their code.

Of course, Scrum Masters using ScrumMaster™ can avoid holding team meetings for sprint planning, daily status updates, and end of sprint retrospectives altogether.  That’s one way to minimize uncomfortable team contact.  But, getting to the source of the issues and dissolving old patterns holds far greater rewards.

NextWaveOnlineTraining.com
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone

Scrum Master: Position or Role?


To our way of thinking, Brian Lawrence nails it.  From the stony silence (and arrogance) he received when he broached the topic in an Agile group meeting to his concluding points.  However you implement Agile, it needs to fit well with your team structure and needs—and expect those needs to change over time.

Companies, organizations, projects, and teams are unique.  Size, project scope, and team talent varies.  One size—one dogmatic Agile approach—can’t fit all, even if it’s a good place to start. 

The definition and expectations of the Scrum Master role in a work environment shape the type of challenges faced when implementing an Agile approach. 

A team may find the natural progression of Agile in their company not only evolves the job of Scrum Master into a rotating role that anyone can do, for some teams, that role becomes that of a scribe:  the primary responsibilities are to run rituals (sprint planning, daily standups, and retrospective meetings), record changes in task status, and identify impediments and solutions that need to be escalated outside team. 

It helps if everyone is clear about the Scrum Master’s functional role within the team and relative to the rest of the organization.  Is the Scrum Master the Scrum dogma enforcer?  An Agile approach coach?  A mentor in Scrum methodology?  What flavour, strict ‘orthodox’ or ‘reformed’?  Couldn’t agree more, top down mandates don’t optimize teamwork or efficiency.  And when the project stalls, the “I followed every Scrum rule in the book” isn’t a valid management defense or excuse!  The only goal is to deliver superior product, on time, on budget.  And not make your team’s life miserable in the process.

Does the Scrum Master work with the product owner to establish priorities from a BUSINESS perspective, or is that handled by the Dev Lead that has a deep understanding of the individual project under discussion?  If you do rotate the Scrum Master role, you may need to separate out that function.

Having lived in these trenches, this is exactly why we built the NextWave ScrumMaster™ Agile project management tool.  Our work tools have to be flexible.  We need to be able to use them as it makes sense in our individual situations.

 

Scrum Master: Position or Role?            

Posted by Brian Lawrence
Nov 05, 2013

A couple months ago I attended a local Agile user’s group meeting and sat in on the Scrum Master Birds of a Feather session. I created a bit of a stir when I first asked, “How many of you have full time Scrum Masters?” All the other organizations represented turned out to have full time Scrum Masters. So, I then asked my second question, “What do they do?” I guess I had asked the question in a way that implied that full time Scrum Masters was strange, because I was greeted by several moments of complete silence. Most of the people, other than those from my own organization, looked at me like I had three heads. Finally, they indulged the obviously under-educated member of the group, namely me, with explanations directly from The Scrum Guide as to what a Scrum Master does. I shocked them further when I said that we had moved beyond the need to have full time Scrum Masters. I didn’t bother telling them that we actually never had full time Scrum Masters.

The Scrum Guide generally describes the Scrum Master role as one of teaching, coaching, facilitating, and removing impediments. And when a Scrum team is new, these things take time. A team new to Scrum tries to follow Scrum by the book and needs someone that can do a lot of teaching, coaching, facilitating and removing impediments. But what happens when the delivery team matures? Teaching lessens. Coaching lessens, though there is still need for coaching around constant improvement. Facilitating is still necessary, though this takes up very little time. And impediments lessen as the team learns to deal with them on their own. If one of the team members’ full time job is teaching, coaching, facilitating, and removing impediments and all these things have lessened to where that person is only needed ten to twenty-five percent of their time, what do they do the rest of their time?

For us, we took the following path. We started with Scrum, though I wouldn’t say strictly by the book. We came from a world where we had project managers running multiple projects, thus working with multiple project teams. Our first step was to train our project managers in Agile. Several of them took advanced courses. A couple even became certified Scrum Masters and Agile Project Managers from the Project Management Institute. Thus, our project managers (PM) became our first Scrum Masters. Due to resourcing constraints (we had more teams than PM’s) and possibly due to a little foresight, we did not immediately dedicate a Scrum Master to a single team. Yes, that’s right, we violated one of the Scrum rules right from the start. Each of our PM’s generally had two teams they worked with as the Scrum Master. This kept them busy, but did not overwhelm them. Their role, as you might guess, was to teach and coach the teams in Scrum, to facilitate the Scrum ceremonies, and to remove team identified impediments. And this worked for the first nine months to a year.

Fortunately for us, our Scrum teams matured. It became apparent to me that our set up with using PM’s for Scrum Masters was starting to become a problem when during employee one to ones I kept getting asked just what value the PMs (notice they were not referred to as Scrum Masters by the team) were adding to their team. The delivery team members felt like they were being over-managed by multiple people. They had their own functional managers and they had Scrum Masters who were not really part of the delivery team.

We made our first change in the structure. Each team was allowed to select their own Scrum Master from among the delivery team members. The Scrum Master would still be responsible as a full time delivery team member, but they would also facilitate the Scrum ceremonies and be the first point of contact for impediments to the team. What did we do with the PM’s? At first we left them as PM’s – doing some project management stuff such as cross-team coordination. But we also left them as Agile coaches. And coaching became something a delivery team asked for, not something that we imposed on them. This worked well. Those teams that were more mature in their Agile approach and understanding didn’t feel over-managed. Those teams still coming up to speed had someone they could go to for coaching.

One more minor transformation occurred as we continued to mature. We elevated the PM’s to program managers rather than project managers. They now became responsible for cross-team initiatives. These are projects that transcend products and have tasks / stories in multiple delivery teams. We also rearranged our management reporting where we went from functional managers / supervisors to delivery team managers / supervisors, a role we call the delivery manager. And it is the delivery manager that is now responsible for the Agile coaching and mentoring. We’re still working the kinks out of this model, but the teams are delivering well, so it seems to be working.

For us, Scrum Masters started as positions and evolved to roles as we became more Agile mature. We took the responsibilities of a Scrum Master and divided out the coaching / teaching parts from the facilitation / impediment removing parts. This works well for us allowing the teams to feel self-managed and allowing them to mature at a sustainable pace, as coaching has become something asked for rather than imposed upon them. It also allows more team members to experience the role, as many of the teams will rotate Scrum Master at set time periods. And we’ve found that any type of delivery team member can be a Scrum Master. We have business analysts, developers, and QA testers all being Scrum Masters. We’ve also found that even the coaching / teaching is staying within the delivery teams with the Scrum Masters, as the ones that gravitate to that role are the ones interesting in learning Agile principles and imparting that learning upon their teams.

Finally, the bottom line that makes management happy is that we have less people doing the same amount of work. We have sixteen delivery teams. Without the need for dedicated Scrum Masters, we’ve saved the need to have sixteen more people and with a fixed budget, that really breaks down to being able to have sixteen delivery teams, rather than only having thirteen teams because we’d need those extra people to fill a position that’s really a role.

My concern and the reason for this article, is really a warning to all of you out there beginning your Agile journey. If you hire a slew of full time Scrum Masters, which is happening at least here in St. Louis, you need to have a contingent plan as to what you’ll do with them as your delivery teams mature. And at least here, most of the Scrum Masters being hired are coming out of a project management background. Nothing wrong with that, but again, be prepared to answer the question, “Okay, now what do we do with all these PM type people that used to be Scrum Masters?”

About the Author

Brian Lawrence is currently an IT Director at TriZetto Provider Solutions in St. Louis, MO, where he is responsible for several Agile and Kanban product development teams, as well as application architecture. He has been a process junky since the days of Edward Yourdan. During his career he’s taken development organizations through several methodology transformations, including Rational Unified Process, Essential Unified Process, and Agile. He loves process improvement and looking at ways of developing software better, faster, and cheaper. His current passion is looking at ways to manage within an Agile environment.

Related Sponsor

 Agile Project Management That Adapts With You.
Provide your global development team a shared space that adapts to the  way they work.

ScrumMaster™ in Action


Here’s how ScrumMaster tools manage Agile projects.

ScrumMaster IS Agile

The tools and project management cycle. WiFi connects the Scrum Master to team members using Agile Story Sizing Cards™.

NextWaveOnlineTraining.com
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone

Dilbert on Project Management


Project planning, resources, and reality.

Dilbert on Project Planning Resources and Reality

Dilbert needs help.  Dilbert needs ScrumMaster™.   😉

How long will your project take?

Using ScrumMaster’s interactive burndown chart, change Target Velocity (two people’s worth?) to see impact on end date.

Dynamic Burndown Target Velocity Analysis

ScrumMaster’s Burndown graph is dynamic. Make a change to Target Velocity and a new end date displays.

Make confidence adjustments, +/- 0-20%

What is the likelihood that ‘The Boss’ (or dev realities) will add more backlog?
Estimating Backlog Variables

Report out

Take a snapshot of the Burndown graph or export the results as Project Status or Burndown reports.

ScrumMaster Project Reports for Export

ScrumMaster Project Reports export to Word, Excel, and PDF formats… ready for you to customize to best suit your needs.

Now add back the new team member complexity and drama factors!

NextWaveOnlineTraining.com
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone

A hike is to project planning as…


If you haven’t seen this before, Michael Wolfe’s software development analogy to a hike that seems so simple in concept is worth it for the laughs… because we all have been there before.  In fact, we deal with this every day.  Posted on Quora and below, in case you have difficulty seeing the article.

Engineering Management:
Why are software development task estimations regularly off by a factor of 2-3?

Michael Wolfe, Startup founder

Let’s take a hike on the coast from San Francisco to Los Angeles to visit our friends in Newport Beach. I’ll whip out my map and draw our route down the coast:

The line is about 400 miles long; we can walk 4 miles per hour for 10 hours per day, so we’ll be there in 10 days. We call our friends and book dinner for next Sunday night, when we will roll in triumphantly at 6 p.m. They can’t wait!

We get up early the next day giddy with the excitement of fresh adventure.  We strap on our backpacks, whip out our map, and plan our first day. We look at the map. Uh oh:

Wow, there are a million little twists and turns on this coast. A 40-mile day will barely get us past Half Moon Bay. This trip is at least 500, not 400 miles.  We call our friends and push back dinner til Tuesday. It is best to be realistic. They are disappointed, but they are looking forward to seeing us. And 12 days from SF to LA still is not bad.

With that unpleasantness out of the way, we head off. Two hours later, we are barely past the zoo. What gives? We look down the trail:

Man, this is slow going! Sand, water, stairs, creeks, angry sea lions! We are walking at most 2 miles per hour, half as fast as we wanted. We can either start walking 20 hours per day, or we can push our friends out another week.  OK, let’s split the difference: we’ll walk 12 hours per day and push our friends out til the following weekend. We call them and delay dinner until the following Sunday. They are a little peeved but say OK, we’ll see you then.

We pitch camp in Moss Beach after a tough 12 hour day. Shit, it takes forever to get these tents up in the wind. We don’t go to bed until midnight. Not a big deal: we’ll iron things out and increase velocity tomorrow.

We oversleep and wake up sore and exhausted at 10 a.m. Fuck! No way we are getting our 12 hours in. We’ll aim for 10, then we can do 14 tomorrow. We grab our stuff and go.

After a slow slog for a couple of hours, I notice my friend limping. Oh shit, blisters. We need to fix this now… we are the kind of team who nips problems in the bud before they slow our velocity. I jog 45 minutes, 3 miles inland to Pescadero, grab some band-aids, and race back to patch up my friend. I’m exhausted, and the sun is going down, so we bail for the day. We go to bed after only covering 6 miles for the day. But we do have fresh supplies. We’ll be fine. We’ll make up the difference tomorrow.

We get up the next morning, bandage up our feet and get going. We turn a corner. Shit! What’s this?

Goddamn map doesn’t show this shit!

We have to walk 3 miles inland, around some fenced-off, federally-protected land, get lost twice, then make it back to the coast around noon. Most of the day gone for one mile of progress. OK, we are *not* calling our friends to push back again. We walk until midnight to try to catch up and get back on schedule.

After a fitful night of sleep in the fog, my friend wakes up in the morning with a raging headache and fever. I ask him if he can rally. “What do you think, asshole, I’ve been walking in freezing fog for 3 days without a break!” OK, today is a loss. Let’s hunker down and recover. Tomorrow we’ll ramp up to 14 hours per day since we’ll be rested and trained… it is only a few more days, so we can do it!

We wake up the next morning groggy. I look at our map:

Holy shit! We are starting day 5 of a 10 day trip and haven’t even left the Bay Area! This is ludicrous! Let’s do the work to make an accurate estimate, call our friends, probably get yelled at, but get a realistic target once and for all.

My friend says, well, we’ve gone 40 miles in 4 days, it is at least a 600 mile trip, so that’s 60 days, probably 70 to be safe. I say, “no f–ing way… yes, I’ve never done this walk before, but I *know* it does not take 70 days to walk from San Francisco to Los Angeles. Our friends are going to laugh at us if we call and tell them we won’t see them until Easter!

I continue, “if you can commit to walking 16 hours a day, we can make up the difference! It will be hard, but this is crunch time. Suck it up!” My friend yells back, “I’m not the one who told our friends we’d make it by Sunday in the first place! You’re killing me because you made a mistake!”

A tense silence falls between us. The phone call goes unmade. I’ll call tomorrow once my comrade regains his senses and is willing to commit to something reasonable.

The next morning, we stay in our tents till a rainstorm blows over. We pack our stuff and shuffle off at 10 a.m. nursing sore muscles and new blisters. The previous night’s fight goes unmentioned, although I snap at my idiot friend when he leaves his water bottle behind, and we have to waste 30 minutes going back to get it.

I make a mental note that we are out of toilet paper and need to stock up when we hit the next town. We turn the corner: a raging river is blocking our path. I feel a massive bout of diarrhea coming on…

Good to know it’s not just your life, eh?  Honestly, some of these issues are exactly what drove us to create the ScrumMaster application.  It’s reality.  And not just for our tech world, the human world.  We’ve come to believe it’s normal.  So let’s just deal with reality and find some better ways to work together and get the job done.

For Agile Story Sizing Cards, not so much… that was more about boring, way-too-long meetings.  What better way to deal with them than to let your mind wander down the, ‘Gee, wouldn’t it be much cooler to be doing this on my phone.  Hmmmmm.’   Solved another problem too: Where did I put my poker planning cards!?!

NextWaveOnlineTraining.com
ScrumMaster Windows 8 Agile Story Sizing Cards Windows 8 Agile Story Sizing Cards Windows 8 Phone