An Expert’s Experience


Seven stories, seven Scrum realities.

Seven stories.  Seven Scrum realities.

Here’s a quick read from InfoQ.  Author Paul VII gives us Scrum confessions that reveal mistakes he made on the job and how he used them to improve.

Table of Contents

  • Introduction
  • Scrum Introduction and Recap
  • The Characters
  • Confession 1: Tools vs. People
  • Confession 2: Release-Planning Peril
  • Confession 3: Intro to Scrum Gone Bad
  • Confession 4: Stand-Up vs. Sprint Review
  • Confession 5: Taking the Team to Task
  • Confession 6: Retrospective Regret
  • Confession 7: The Bloated Bug Backlog

Topics sound familiar?  You are not alone.  Each is worth reflection.  Maybe even a discussion with your team.

Enjoy!

2014 Tech & Marketing Trends


We may be rogue app creators but there is always the people side of the business to consider… be it the team, client, end user, or potential end users.  Or dev partners.   😉

What is Rogue IT?

We find we’re already living some of these 2014 marketing predictions from the New York #tech community, posted by Jacob Ajwani.  It’s tougher every day to manage the complexity but therein lies the opportunity.

It’s reassuring to see our instincts seem to be right: create companion apps that make life EASIER as they operate natively independently and interdependently.

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

Another Alternative Burndown Chart


Reality… average velocity changes throughout a project.  For any number of reasons—level of work, its difficulty, spikes, staff changes, holidays, etc.  No two sprints are the same in terms of content so it’s not reasonable to expect velocity to stay the same from one sprint to another.  Therefore, it can’t be the only variable to use to predict your final sprint.

Backlog changes too.  This is normal.  It just makes project tracking difficult unless you have a tool like NextWave ScrumMaster™.

Reading Mick Cohn’s article, Alternative Release Burndown Chart, reminded us why we designed the interactive ScrumMaster™ Burndown graph to project and handle backlog, velocity, and end dates the way we did.

As Mike points out,

“For example, suppose a team had expected to make progress of 40 hours, points (or whatever) last sprint, but the burndown chart only shows net progress of 10. Was the team slower than expected, or was more work added to the release?
It’s important to know the answer to this question, because we cannot really predict when the release will be done without it.”

Absolutely, and Mike shows you how to handle it using Excel.

Or, you can let ScrumMaster do the work for you and then some.  As you can see in the video, ScrumMaster automatically projects your ending sprint.  It also shows you when, where, and how your backlog grew.

If you are using ScrumMaster, here’s how it differs from Mike’s Alternative Burndown Chart.

  • Projections to finish date are simpler… and ScrumMaster does it all.
  • Want to see the trend line to project finish?  Choose the Average velocity menu option and you get the classic projection.
  • Backlog is automatically adjusted at each Retrospective (purple dotted line).  You don’t have to add anything.
  • All task work is color-coded, Original work plus any new work (Added tasks, Issues found, Software bug, Spike, Technical debt, Meetings).  There’s a ScrumMaster Report that tracks and analyses Backlog by type, by sprint.
  • You can select confidence levels for velocity and backlog estimates, to make automatic percentage adjustments to the projected ending sprint.  The greatest impact is usually seen early in the project cycle.
Estimating Agile Project End Dates

The interactive Burndown graph shows your project’s last sprint.

Make sense?  Give us a shout if you have any questions or comments.

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

Agile Problem Analysis


The Wheel of Life, the ancient Tibetan Dharmacakra symbol, represents dharma, the Buddha‘s teaching of the path to enlightenment.

Tibetan Dharmacakra Symbol

Dharmacakra: Tibetan Wheel of Life

Here is the NextWave Retrospective wheel we’ve created as a discussion tool.  We use it during #Retrospectives for sprint post-mortem discussions.

NextWave Retrospective Tool for Agile Analysis

NextWave Retrospective Tool for Agile Problem Analysis

As a mirrored variation of dharmachakra, it appeals to us and evokes the iterative cycle of waves… and the #Agile cycle.

We’ve found it to be useful to help us structure our thinking about any problem we’re analyzing.

Question #1:  We’ve defined a problem.
What’s its real source?

People?  (You?  Me?  Us?)

Process?  (How, who, when, what, where, why…?)

Or Product (Our understanding of the requirements?  The code itself?  Our approach?)

Once we’ve identified potential source(s), we ask: ‘Is the root of the problem at its source a Knowledge, Skills, or Attitude issue?’

Reflection and discussion often yield interesting insights.

Triangle of Success

Cool.  So now we think we understand the sources of the problem (there’s usually more than one).

Question #2:  What can I/we do about it?

Back to the NextWave Retrospective wheel.  Where, when and how can I/we impact change involving PeopleProcessProduct?  What will it take to bring about the change?  Who’s involved?  How?  Who’s taking responsibility to follow up with action?

And so the cycles and discussions continue…

Re-blog: Agile and Torque?


Cross-fertilization of ideas and inter-disciplinary analogies!

POWER (the rate of doing WORK) is dependent on TORQUE and RPM (the MEASURED quantities of engine output).

In Agile environments, does a similar relationship exist between Velocity and the team’s ‘torque’, the sum of each individual team member’s effort?

The extension of the ‘Knowledge-Skills-Attitude’ trilogy for success into a concept of project ‘work torque’ is a very interesting idea, introduced in Vinko Novak’s blog reposted below.

Triangle of Success

Think about it for a moment.  You’re always looking for ways to improve your team’s performance, or perhaps you’re facing a more specific issue, e.g., your team is struggling to use patterns effectively.  Why?

No finger pointing here!  As a management and basic problem solving tool rigorously applied, considering if a KSA area is the source of a team’s challenges could be a good first step that helps focus where potential improvements can yield the best ROI — whatever the desired outcome is or how it is measured.

Next, deeper analysis and reflection.  For the patterns example, is it really Knowledge or Skills that an individual or the team is lacking?  If so, those can be handled with relative ease, in a number of ways.  Is it Attitude?  If so, determine who, why, and the real sources of discontent.  Specifically tailor PEOPLE solutions to address those root causes.

However, perhaps the challenge isn’t about improving team KSA at all.  Could the source of the problem be as ‘simple’ as ineffectual communication about the patterns’ philosophy or use?  Or, the actual patterns themselves in this particular solution?  And what role does process play?

The variables are always many and complex, but the first step to finding a real solution is to deal with reality, as best as it can be determined.  The standard advice:  Make sure the right questions have been asked.  Make sure any responses address root cause.  And know that facing the possible answers sometimes takes courage!

REBLOG

See more from Vinko Novak at http://threelionheads.wordpress.com/.

Increasing Velocity by increasing the Team-Member Torque

SCRUM seems to be much about velocity and acceleration. So let’s stick to car terminology for a moment. If it is all about velocity and acceleration than contribution of each team member must be something like torque. Here is an interesting learn model I found very useful to define the actual torque. It’s called KSA (Knowledge, Skills and Attitude) model.

ksa

Knowledge is practically all a person knows and includes theoretical and practical learning. Everything you learn from experience is also knowledge. While applying the knowledge to the work, while practicing, you acquire or strengthen your skills. Skills are about how well you do things. For example programming skills, presentations skills and communications skills are common to software engineering. Attitude, from my point of view, is about how willing you are to do your work.

A scale factor for each layer of the model multiplied together gives the torque of the individual team member.

Lets define a scale, say 0 to 10, where 0 means not existing and 10 is maximum achievable value.

#example Having 7 in knowledge and in skills means 10 years or more of experience in certain field while continuously improving and learning ever since. But with a 3 in attitude you are probably dealing with the typical team member in “Waterfall”- organisations. The calculated torque for such a team member is  7x7x3=147. Out of 1000.

If SCRUM succeeds to change the attitude of the team members by more engagement, free decision making, clear focus, responsibility, commitment etc. the torque of each team member can rise dramatically (e.g. if we change the attitude in the example from 3 to 7 we get 7x7x7=343). This doubling in the torque might be a reason for the rise of velocity in SCRUM projects.

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

Lean Startups Living Agile


At NextWave, we’re Agile.  Not just in the way we develop applications and how we put ourselves, our company, and our products out there.

We appreciate the fact that Life is iterative, at every level.  And an experiment.

Agile in Nature

Agile in Nature

“The problem is that quality is really in the eye of the beholder. For a for-profit company, quality is defined by what the customer wants.”
~  Eric Ries

That would be YOU.  For us to constantly improve, we need to know what you like and don’t like about any ScrumMaster application.  Speak up!  Share your experiences with our blog site community.  Feedback and quality go hand-in-hand.

And if you’re not familiar with Eric Ries and some of his thoughts about Lean Startup, you may want to check him out.  Here’s just one interview with LinkedIn Executive Chairman and co-founder Reid Hoffman about what quality should mean for entrepreneurs.