The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

9th
MAY

Scrum based funding model – 20 percent

Posted by ewok_bbq under Agile and Scrum, Scrum Basics

Sorry for the long pause between blog posts.  I’ve been traveling way too much lately.  This week I was excited to participate in the Scrum Gathering in Las Vegas (you can search through twitter utilizing this hashtag #sglas).

I saw many industry colleagues and re-connected with folks like Lyssa Adkins whom I hadn’t seen in a year or more.  I attended a number of sessions and I had two favorites.  One was on removing impediments with drawings, see: http://www.scrumalliance.org/events/610-las-vegas-#program003 where I will do a write up on that session in a later blog post.
My other favorite will be the focus of this blog post.  It was the keynote session by Jeff Sutherland, PhD and co-Creator of the Scrum framework.  The topic was called Scrum: The Future of Work
The thing that caught my ear about his talk was his concept of moving to a 20% funding model for new product development teams (see slide number eight here: http://scrumlab.scruminc.com/gallery/slideshow/album-104).  That is to say, stop funding projects at the 100% level.  Instead, businesses can quintuple down their business bets by investing 20% of their money across five different projects. The portfolio managers, Uber POs, business stakeholders can stop incrementally at the 20% stage of the budget cycle to re-evaluate and re-organize teams by examining the business delivered between the five separately funded projects.
The POs of each individual project will be re-evaluated based on value delivery and predictability at only a 20% timeline. At the end of each release or budget cycle – the individual POs can re-request additional money based on the value delivered not on how ‘busy or efficient’ we are keeping individual team members – which in turn keeps prod dev teams continuously pushing hard because they only get 20% of their funding.  It also tests the long held 80/20 rule which states that you can deliver 80% of the value in 20% of the time.  Because the teams are developing vertically your sol’n are ready to get pushed into production at the end of the 20% budget cycle for immediate customer feedback.  If you have a predicable team doing the work you will know how much value you will deliver well ahead of the release and as a portfolio mgr you can make adjustments to your five bets based on that metric not on whether Bob or Sally seem busy today.
What are the pre-requisites to make this work? 
  • Stable cross functional teams with known velocities.  You won’t compare velocities of the team (that’s bad form), but you can compare their relative increases against one another as part of your funding decisions.  From there – you can compare relative velocity growth to the costs of your team to get a cost per feature metric which can then be evaluated against your Earned Value or Agile EV Metrics.   If you aren’t doing this – please do consider calling CollabNet so I can help get this set up for you and your teams.
  • A FOSS based software environment that compliments the elasticity of Cloud Deployment strategies.  A non FOSS environments means having enough commercial licensing in place to meet the demands of autonomous teams using elasticity to map to continuous deployment strategies.  This doesn’t work in most regulated industries so be careful if you have external compliance here.
  • Building in vertical slices so that we can push to deployment and leverage (b) above.
  •  Having the ability to measure ‘business value delivery’ vs. saying ‘efficiency of individuals’ – see the EVM stuff in (a) above.
  • Your accounting team / source of financing needs to be able to re-evaluate investments more often than a yearly budgeting cycle
If you don’t have these prerequisites in place work on getting those in place before trying the above.
Happy scrumming.
Tags: ,

2nd
APR

What is Agile ALM

Posted by ewok_bbq under Agile and Scrum, Agile Assessment, Agile Principles, Scrum Basics

I was asked to speak recently on a panel at the EclipseCon 2013 event in Boston.  The panel included the Co-Creator of Scrum, Ken Schwaber as well as Forrester Analyst Tom Grant. The link to the panel discussion is here

 

In preparation for the event I wanted to articulate to myself what does “Agile ALM” mean to me today. I wrote about Agile ALM a few years ago here but the definition and the article seemed a bit stale.  So here’s my new definition,

 

Agile ALM is the ability to build and deconstruct intelligent and actionable traceability through the life and retirement of an application leveraging the ethos of learning.

 

What do you think?

Tags:

5th
FEB

Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting?

Posted by MJ under Agile and Scrum, Scrum Discussion, Scrum Transitions, transformation

[Editor's note: this is a guest post from Michael James, not the owner of this blog.  The owner of this blog does not necessarily agree with any or all of the content herein.]


I’ve been talking with some Scrum trainers who’ve been working on a new definition of Scrum.  While Scrum already has a few simple non-prescriptive rules, the trainers are falling into the trap of converting their usual preferences into overly prescriptive rules.  For example, it is often beneficial for the team to include the Product Owner in the Sprint Retrospective Meeting.  There are also several circumstances (particularly when we’re first switching from traditional command management to Scrum) where this might not be the best thing to do.  After nearly 100 posts in the discussion, one esteemed fellow stated the root misconception:

All the objections that have been brought up seem to me to be trying to work around the rather obvious impediment of someone acting badly.



No, that’s not it at all.  I agree if the Product Owner (or anyone) is being a jerk, this is an obvious thing for the Scrum Master (and others) to fix.  My concern is something much less obvious, and (in my experience) more powerful.  As I’ve written it out below, I realize it’s also more complicated to explain than I first thought.

  1. It is normal human nature to overestimate what we are able to perceive about a situation.  We never grasp the full extent of this because we lie to ourselves about the fact we lie to ourselves.
  2. As Keith Johnstone (the father of theater improv) also observes, there are no status-free transactions among humans.  None.  (By the way, learning theater improv is an exciting way to learn how true collaboration really works.)
  3. 99.9% of organizations designate material power to some individuals over others.  I’ll call them “bosses” and “subordinates” instead of the various euphemisms.  While most bosses don’t enjoy this, they are burdened with deciding which subordinates will be retained in the event of a layoff, which subordinates get promoted, who gets to work on the new sexy projects vs. maintaining the turkeys, etc.  (Some bosses tell me they really hate doing performance appraisals.)  The 0.1% exceptions (maybe Valve?) are probably past the point they need Scrum rules anyway.
  4. The people with the vision, authority, business acumen, and maturity to be good Product Owners are also often burdened by the organization with some boss responsibilities.
  5. It is human nature to assume others are feeling the way we are.  For example, once before I ran a retrospective, a team member told me it was not necessary to waste time on a safety check because they were all very comfortable with each other.  I did one anyway (anonymously, using a hat), which revealed some team members felt quite unsafe.  Confident people overestimate the comfort of others.
  6. Combine all the above and you get the “invisible gun effect.”  THE INVISIBLE GUN EFFECT HAPPENS EVEN WITH THE NICEST BOSS IN THE WORLD.  It’s not caused by the boss’s actual actions, it’s caused by the way subordinate behavior is naturally distorted around bosses.  It’s normal human nature, not something Scrum Masters can “fix” any more than they can fix gravity.  It’s most visible to the lower-status people (which might include newhires, people with less impressive job titles, etc.), less visible to higher-status people (perhaps including senior developers, socially confident people, people with better technical skills than social perception skills, and Scrum consultants), and practically invisible to bosses who haven’t done an A/B test yet.  Nearly everyone in the discussion had reduced awareness of the invisible gun effect due to spending the past few years in relatively high-status occupations: trainers, expert consultants, senior developers, Product Owners, business owners, authors, etc.  The fact that all 104 messages in the thread were written by men might also suggest some blind spots.
  7. There is also what my wife calls the “chirping bird effect.”  I once read that when a male bird is around, a female bird will feign incompetence at something she’d normally be able to do.  My wife brought this up when I asked her how she was able to solve a problem with her computer — something she’d been bugging me to fix — while I was on a business trip.  This effect is gender neutral: when she’s gone I have no problem with things I seem less able to do unassisted when she’s home, such as finding my car keys or preparing food for our kids.  In class we sometimes get groups that keep asking the trainer for more detailed instructions, or help manage another team member.  That’s often a good time for the trainer to leave the room!  We can talk about self organization until we’re blue in the face, and they won’t really get it until we leave them alone — temporarily — to let them do it.  I heard a story of one Scrum coach taking a nap under the table to get a team to step up more, and of Ken Schwaber standing outside the door of the team room during a Daily Scrum.  I’ve seen teams have breakthroughs in self management when the person traditionally responsible for managing them left the room.  I am inspired by the breakthroughs Scrum led to, especially among the lower status team members who aren’t well represented in this discussion.  Team expecting micromanagement?  Try management by leaving the room — temporarily.  Of course we always hold the team accountable at the Sprint Review Meeting.
  8. Facilitators need to learn that when safety is low, smaller breakout groups often work better.  For example I’ve noticed some people in Finland aren’t inclined to talk in front of a larger group (especially in English), but liven up in small groups.  Once they’ve discussed some things in their small groups they’re more comfortable sharing with the larger group.  The paradox here is that appropriate and temporary boundaries can actually increase transparency.




It seems inevitable that the new Scrum definition will include a rule requiring the Product Owner to attend the Sprint Retrospective, and maybe this will turn out to be a good thing on balance.  The new definition should warn about the downsides of requiring the Product Owner in all circumstances, and offer suggestions to mitigate them.  For example, it should mention safety check procedures and breakout groups.


–mj
(Michael)


To learn more about invisible guns and safety checks, see the free Sprint Retrospective Meeting e-learning module:
Invisible Gun in the Sprint Retrospective Meeting


 

.


 

Tags:

28th
DEC

Discretionary Energy and Paul O’Neill

Posted by ewok_bbq under Agile and Scrum

A few days ago I paul_o_picwatched a CNN special produced by Fareed Zakaria Editor-at-Large of TIME Magazine which featured an interview with the 72nd US Treasury Secretary Paul O’Neill.  For those who missed the program I wanted to offer a summary of the piece as well as some follow on analysis.  As usual, I encourage all of the readers to submit comments in the comments section below.

 

Before becoming the 72nd US Treasury Secretary Mr. O’Neill was the CEO of Alcoa.  When he came into the organization, by all accounts Alcoa was lagging behind in terms of both employee morale and revenues and not delighting users.  Instead of focusing on increasing revenues, Mr. O’Neill zeroed in on safety.   At first glance it seemed like a very curious choice and one that did get immediate negative feedback from his management team and some of the long time tenured employees at Alcoa.

 

So why would a new CEO spend most of his time on an initiative focused on safety?  Really, how would that lead to profit and revenue growth?  The answer is the concept of Discretionary Energy.

 

Discretionary energy is the amount of attention you are getting from your employees and it speaks to their willingness to be “checked-in” vs. their willingness to be “checked-out” during work hours.  What Mr. O’Neill recognized was that there was a correlation between his employees’ safety violations decreasing and discretionary energy increasing. Amazingly, even with his internal detractors, his theory played out.  What he saw was a huge decrease in safety violations and a huge increase in discretionary energy.

 

Once the employee base discretionary energy was at a heightened level, Mr. O’Neill could begin leveraging his successful experiment by rolling out additional top-down initiatives that would spur additional activities / yielding results that he wanted.  With employees already going the extra mile and sending additional energy around safety it wouldn’t be a stretch to ask them to do the same around other tasks.

 

When you go back to work after the first of the year, ask yourself –how much discretionary energy are you spending at work? How much is being asked of you (are you allowing yourself to be checked out)?  And if you are a manager ask yourself, what you can ask your team to focus on that would heighten their discretionary energy levels.

 

 

Tags: , ,

17th
DEC

Do People Matter?

Posted by ewok_bbq under Agile and Scrum, Agile Manifesto, Agile Principles

301770_555175034510479_1019421605_nHopefully the title of this blog post got your attention.  Culture seems to be at the core of what is important these days.  Many authors like Dan Pink, Steve Denning and Jurgen Appelo are making strong cases for the import of recruiting and retention programs as a means of building ground-up innovative companies.  Many of the arguments from these thought leaders have been built on shoulders of the top management thinkers of yesteryear.  Folks like Tom DeMarco who claimed that workers were different than say machines because of humans’ non-fungible characteristics.  If you haven’t read Slack yet, please do go out and buy it.  It’s well worth the money and time and would make a perfect stocking stuffer.

When you do recruiting for your team, what are the criteria’s you choose your candidates by? How highly ranked is culture versus say competence? See what Brad Feld of WSJ has to say here.  Do you agree?

While I was the President and Co-Founder of Danube, I did a lot of the recruiting.  But, really, I only looked at three things.  Here they are in order of priority:

  • Culture Fit.  Our office in Portland was tough.  There were a lot of very strong women working in a collaborative sales environment.  This was very intimidating to many of the salesmen I interviewed who were used to individual quotas and goals [incentive structures are a topic for another blog post I am sure].
  • Type-A personality or a Willingness to make decisions.  Was the person a slacker or a go getter? Really – I have nothing against slackers but I can’t work with them in the business world.  I am simply not interested.   Moreover, I hate it when employees don’t feel empowered to make decisions – big or small.  As I always told employees, I may be temporarily angry with you for a decision you’ve made that I didn’t agree with, but I’ll terminate your employment contract for not making a decision when a decision was called for. I can’t be everywhere always – so the groups I manage need to think for themselves given the nature of the information in front of them and act.
  • Intellectually curious.     I want people who have a thirst and desire to learn new things every moment of every day.  If you’re not having rigorous debates and learning through exploration –you wouldn’t have been a fit at Danube.

You will see that I simply didn’t evaluate based on keyword experiences.  Sure – it matters, but ultimately you can learn just about anything (Salesforce, QuickBooks, Ruby, Scrum, etc).  So – to me, culture is way more important than competence.  Do you agree or do you think that culture isn’t material when building a business? I would love to hear from the readership in the comments section below.

 

 

 

Tags: , , , , , ,

30th
NOV

Culture at the core

Posted by admin under Agile and Scrum, Agile Assessment, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

Here’s a link to a number of blog posts I’ve been reading that have culture and transformation at the core.  I’ve aggregated my favorites.   Feel free to add to the list below in the comments section.  I’ll respond with what I think.

  • Here’s an article I stumbled upon while reading LinkedIn.  It’s written by Jeff DeGraff a Professor from the US.  In it, he talks about culture change vs. culture growth and digs back into his Hungarian roots (yay!  He’s Hungarian just like me).   Have a read here http://linkd.in/U6rPjj
  • If you are new to systems thinking, here’s a great blog post I read by John Wenger: bit.ly/10HzGec 
  • What is DevOps anyways? With all the hype around Developer Operations or DevOps – this blogger reminds us to consider that it’s culture at the middle http://bit.ly/UfH0sX
Tags: , ,

24th
OCT

Special early bird pricing for ScrumMaster certification class

Posted by admin under Agile and Scrum, Scrum Basics

My colleagues at CollabNet are running a special promotion for Scrum training classes in a few of their most popular locations:  New York and San Francisco.  I’m really not sure they they are lowering the price for early bird registrations, and I don’t know if it will be permanent.  However, if you are considering ScrumMaster certification classes and want a discount, I definitely encourage you to check them out.  You don’t need a promo code – just go through the normal registration process and you should get the low price.  See the classes in New York, San Francisco (December 4 and December 18 – a course for product owners) and San Jose, CA.

Tags:

3rd
JAN

Results of an Agile Assessment

Posted by admin under Agile and Scrum, Agile Assessment, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

We recently set a team of consultants from my company to conduct a formal assessment of a medium sized financial firm’s an Agile capabilities. I’d like to share thew approach here. The team went on site to conduct interviews and observations in 5 areas –

• Value delivery
• Agile engineering
• Project Management
• Product management
• Environment and Organizational Culture

Also, the investigation took input on the demographics of the individual project being examined, the stakeholders involved and the competitive/regulatory environment in which the organization as a whole operates. Understanding the context in which an organization operates is crucial to understanding the optimal level of Agility, and thus, the plan of action.

Understanding the goals of the organization is particularly important. Not every axis needs to be top-ranked to achieve the company’s goals. In fact, on this particular assessment we found that only one needed urgent attention – Project Management. I’ll provide details in another post.

Tags: , , , ,

20th
DEC

Introduction to Scrum Video

Posted by admin under Agile and Scrum, Agile Manifesto, Agile Principles, Scrum Basics

A colleague of mine, Michael James, just posted his Introduction to Scrum video on YouTube. You might want to take a look and/or pass this link to your colleagues. The full series is available at http://ScrumTrainingSeries.com.

I think is the right length and depth for an overview of Scrum – it’s not so short as to be trite (or worse, incorrect), but it’s not an exhaustive examination of Scrum either. This video is good prep for people who are planning to enter a ScrumMaster class and don’t want to go in cold. It is also good for stakeholders around the company who want an understanding of Scrum so that they can work better with their development teams.

I’d be very interested in hearing your views of this video.

Tags: , ,

12th
DEC

Complexity and cost of change

Posted by admin under Agile and Scrum, Scrum Basics, Scrum Discussion

There are many variables to estimating the difficulty of a code changes. We could talk about things like the complexity of the code (Cyclomatic Complexity), the experience of the programmers, their familiarity with the topic and/or the specific module, the quality of documentation, etc. It ends up being a fairly subjective estimate. In Scrum teams, story sizes are estimated in relative terms in terms of story points.

The primary benefit to using a technique involving Relative Estimates is that you are asking the team to give you an estimate of difficulty relative to other work that has already been completed. This means that a team can easily give judgments like “This will be twice as hard as that” and come up with functional estimations for predictions without spending a great deal of time coming up with them. Estimates are just subjective guesses anyway, understanding that can be a valuable way to put more time into building something and less time into trying to guess how much time it will be to build it. Planning Poker, also called Scrum poker, is one technique for building relative estimates and for coming to consensus on the effort or relative size of the stories.

Tags: , , , , ,