Agile Influencers of DC

This past Friday, 11 May 2012  we held a session on Sustainability.  We first tried to determine what we meant by sustainability and this was the list we came up with:

• Team sustainability (ability to continue delivery)
• Sustainability of purpose/community
•  Preventing burnout (related closely to the first bullet)
• Sustainability of a product feature
• Sustainability for continual improvement

This list generated a bit of discussion.  Siraj and I have been a bit concerned that the group isn’t quite sustainable yet (perhaps self-sustainable is what we are really meaning?).   This led to us discussing a bit abut the purpose of AID, and hopefully I’ll recap thissuccessfully that we formed shortly after Agile Coach Camp 2010 to bring together those that need to influence others in adopting and continuing practices of Agile through peer-based sharing.  These may be coaches, managers, or technical personnel.

To ensure we were on the same page, we decided to create a definition of Sustainability and we used a mind map.  Here was our initial version (with some minor tweaks):

 We developed 4 primary characteristics: Sustenance, Tension Pace, and Feedback.  Each of these had characteristics as well…  The only tweaks I made to this diagram is the addition of conversations in the Feedback area as measures and metrics have an assumption of precision that may not be there and renaming “Throttle” to Tension as we moved more completely to a motor vehicle metaphor when we began reorganizing the mind map.  (Bio-)Physics means not only what is against the known laws of the universe, but also violating people’s downtime and ability recover.

Later we decided that the mind map was a bit different…  And this was the refined mind map:

 In this map, we saw Pace as the point between Fuel and Throttle (what moves you forward and what holds you back).  In the ideal situation, Pace would be close to Fuel meaning you are churning through the factors (Demand, Need, etc.) as quickly as possible.  Realistically though you have a Throttle holding you back so the Pace is reasonable.  Feedback effects the Pace you maintain as well as the Fuel and Throttle itself. (BTW, I’d consider adding De-motivation to Throttle personally, but I didn’t add it to the diagram as I am not sure that would have much buy-in from our group. I think conversations would have gained considerable buy-in based on how our discussion went.)

We then decided to apply the measures/metrics to understand the Pace of our AID group a bit better and determine if any changes needed to be made.  Here is what we recorded:

We arrived at some of the changes annotated above after a brainstorm (again using a mind-map).  Here’s what we came up with…

So with that, look for an email changing things a bit…  Lastly, here was the list of themes we developed (look for dot poll sometime soon):

• Retrospectives
• Leadership
• Interfaces 
• Mindset
• Career Development/Mentoring
• Learning/Outreach
• Overcoming Resistance 
• Active Listening
• Providing Feedback
• Tech Topics (though we realize due to the diversity of languages and such that this may need to be more generalized)
• Games/Workshop Day

 I’ll close in that with the above, we will probably try and divide each topic into something more focused on a technical team and then something more generalized that managers/leaders may want.  Example, what forms of technical feedback can be developed and how would it be implemeneted (e.g. unit testing) while also discussing more general feedback  (e.g. customer satisfaction).

We’re looking at a having a picnic/BBQ as well; please hold aside 30 June to join in…

- Paul 

The US Agile Coach Camp just completed and several people asked what my play list was that I had running as people gathered. Well, here you go!

30 Minutes - Tatu (Russian album, not the English translation)
Harem - Sarah Brightman
Computer Love - Glass Candy
Hairy Trees - Goldfrapp
Breathe - Telepopmusik
Downward Pull of Heaven’s Force - Babble
Tribe - Babble
Miserei Mei - Sarah Brightman
Beautiful - Sarah Brightman
Suave Suave - B-tribe
Astral Hymn - Solar twins
Face in the Crowd - Kosheen
Perezagruzka (Robot’s Outro) - PPK
Opening Credits - Hybrid
If I Survive - Hybrid
Smokebomb - Ursula 1000
Flying to Frisco - Flying Pops
Jim Clark Theorem - grand Tourism
Circles - Adam F)
Lost in Love (Dj Taucher Radio Edit) - Legend B
What’s on Your Mind (Pure Energy) - Information Society
Big Time - Peter Gabriel
Watch us Work It - Devo

This is about 2 hours of music and we never got through it, but if i were going to have a longer time, there are a few tunes I’d think about adding to this -

Silent Fish - Jens Buchert (insert between Flying to Frisco and Jim Clark Theorem)
Microscopic - Gas
The Smell Of Wet Rocks - Mind Soup
(insert both of these in this order at the beginning)

Enjoy!
Paul

Because it fell during the week of 4 July, the meeting for 8 July was moved to 15 July.  We’re also starting at 5:30pm instead of 5pm to give folks more time to get there.  For July, we’re still at Argia’s, but we’ve had offers for both in Tyson’s and Downtown and we’ll probably move to rotating around to allow folks to attend.  If you sign up on Eventbrite, while it still says the 8th, we’ll consider it the 15th.

I normally don’t comment much when luminaries have debates (I’ll call them debates as they aren’t arguments, but there is disagreement and a desire by each side to win those to other sides), but I think I’ll weigh in…

The debate is over whether the concept of Software Craftsmanship as a (separate) Community/Movement is helpful or hurtful to the Agile Community and more importantly how those of us in Software Development serve our customers  It all stems from comments made by various members that are well respected taking up sides so to speak.  Bob Martin (@unclebobmartin) sees making the distinction as helpful as it shows that programmers are focused on quality and commitment to doing a good  great job.  Martin Fowler (@martinfowler) sees it as pulling the overall Software Development Community and Business apart to some degree.

Here’s my take….

The comments seems to be stemming from the fact that many non-software development domains are latching onto the concept of Agile as the Agile Software Development Community is using it (notice I added Software Development into this…) and it is diluting it.  This is not a legitimate concern IMHO.  Why shouldn’t other groups take advantage of the principles, practices, and techniques we have come up with…  So it’s filled with PMs?  Well, you need them on board! (see Note I added below)  If you don’t get them on board, you’ll have them (with generally more clout) resisting.  You want them becoming proponents (there is one thing that could be talked about more and that is Servant Leadership, but that will be a topic for another day).  The point is there is an Agile Community that has grown to become a superset of the Agile Software Development Community.   The issue is that people aren’t drawing that distinction when they toss around the word Agile.  

We need to…

Some conferences should serve both.  Some should be specific to their domain (e.g. Agile HR, Agile Marketing, Agile Manufacturing, and Agile Software Development). And all communities could learn from one another as we are all linked in the real business world.  Just as the PMBOK started with one basic domain and then became domain specific, so is the Agile Community.  It just started more from a set of grassroots developer-leaders and not from a management perspective. Let’s emphasize that the Agile Software Development Community also focuses on sets of practices; practices that the other domains will develop in time.  Some in existence are directly applicable, like  creating acceptance tests before going off and doing work.  Others less so….

(Side note on Acceptance tests: I had the opportunity to work on a recent engineering project with a fabric manufacturer thanks to some Navy Reserve work where the guy was applying TDD, to manufacturing fabrics - it was amazing to realize.  He didn’t call it TDD though, but the first thing he thought of and conveyed to me as the program manger was how he would approach making a test that shows he would pass the criteria being articulated.  This is why I am confident other domains can take advantage of what we are doing.)

So talking about (and obviously believing in) craftsmanship I think is useful; trying to make it a separate movement less so as we are JUST starting to get traction in many businesses on Agile Software Development.  We don’t need to obfuscate with additional language.

Revised 1/22/11 to correct some grammar issues and add my note

NOTE: In my talk about getting success with Agile in the Federal Government, I talk about the intrinsic motivation at least most developers have when they get their degrees (or start programming for those that don’t get degrees).   They have a passion for doing what they think is right and want to become better at it.  I also discuss that programming is a craft - it has both skills and creativity (it is supported with engineering practices, but as a pure knowledge domain, I wouldn’t call it an engineering).  It takes this intrinsic motivation for the craft (a desire for good craftsmanship) and top down support of management (the business) for Agile, specifically Agile Software Development, to succeed IMHO.

I had the opportunity to both give a couple of talks as well as host an open Space talk on Product Ownership in the Government. I opened the discussion for the group to discuss the “why” for wanting to have a product owner when in most places in the Government this isn’t very high on the priority for standing up a project. We captured 3 reasons:

1) Ensuring the team delivers value to the Government business users.
2) Providing new features that have been prioritized and reviewed as they are implemented; this lowers the surprise factor.
3) Providing a vehicle for the business to participate in the needed continuous improvement for software delivery.

We next tried to capture some ideas that we felt should be used to get the business to provide the product owner in the first place; something that particularly in the Government gets ignored.

One is to rely on a project charter and to spell out that role explicitly in the charter so that the business knows they are signing up to it. Preferably IT/management could use this as a leverage that if the business is unwilling to provide the product owner, the project must not be important enough to fund/develop.

Another option is to have the traditional PM rile transition to becoming the Product Owner, but often the PM also would become the Scrum Master, so some conflict of interest could occur if the roles are not decoupled. A business analyst could be used as well. The primary issue though for either of these is that analysts and PMs come from the IT side and not the business, so there is some conflict of interest as well as just not knowing the business as well.

In a fee-for-service arrangement, it could work that who ever the sponsor providing the money for the project is, they could name any trusted agent to be the product owner if they didn’t want to take on that role themselves.

Another option is for IT to create temporary details that business people get slotted to fill. These could have a temporary promotion to encourage a desire to participate. Because the folks are from the business, they come with the needed knowledge; they also gain an appreciation of the IT world as well. When they come over, their job can now be dedicated as being nothing but the product owner. This eliminates the usual problem of it being a collateral duty for most business folks.

We then moved to discussing how to scale this arrangement and often you here of a Scrum-of-Scrums (in the Scrum world) for scaling Scrum up for larger projects; these could include the product owners as well so that th priorities could be reviewed and perhaps juggled a little for cross-project dependencies.

A few things specific characteristics about the projects the Product Owners are to support should be articulated to them (if they are not the sponsor); the goals, constraining budgets, and any particular schedule demands (need by dates) should clearly be provided (probably in the charter as well). Then the Scrum Master/Team should articulate to the Product Owner when subject matter experts beyond the knowledge of the Product Owner are need and the time required so they can be made available at the appropriate time in the Sprint/iteration. This should be done in the Sprint planning session, but at also the Product Owner should be made aware of the need to talks within someone with subject knowledge during release planning. Schedules can then be adjusted if a subject matter expert isn’t available at a specific time or a back-up individual can be found. the Product owner needs to understand they are expected at the Sprint Review, Sprint Planning, Retrospectives, and Daily Stand-ups and should be available to handle questions in realtime from developers.

We closed with a brief discussion about the sustained agility concept of using a Kanban to feed Sprint teams “ready requirements” to be finalized in the individual Sprints. This has been useful for regulated environments (of which the Government is one). If this is being done, the Product Owner should own this pipeline. This concept was originally brought to my attention by David Bulkin of Lithespeed.

This was a great conference and the open space type of talks tend to be very informative as you learn from other practitioners about the trials and successes they are having in implementing Agile practices.

For our 10 September meeting, we discussed around a theme of estimation.  We started with some lightning talks that progressed into heavier discussions on Estimation.  These lightning talks were as follows:

Paul - A review of sorts of Dan Roam’s book, “Unfolding the Napkin”, which is about solving and communicating complex problems with simple pictures.  These often can be used in estimation or to communicate a plan with its estimates as opposed to more complicated diagrams such as Gantt charts which are more difficult to follow. 

Manoj - discussed estimations around the inability to see the future; he titled his talk “You’re going to be wrong, so be wrong quick”.  In it he discussed how estimation is of course very hard, few teams use evidence based information in estimating and take a bottoms up approach to making estimates.  This produces quite a few errors and the point is to get started on the work so that these errors can be discovered and resolved quickly.

Ken - he had the discussion around “It’s in your genes!” essentially discussing the human side of estimation and that our brains are wired for pessimism, optimism, or any other form of error when we simply have to give estimates.  Ways to help resolve this is looking at evidence, anecdotal or statistical evidence from previous work and then using it as a starting point for the team developing estimates.  Additionally, having the team participate even in a bottoms up approach removes some error as a single person isn’t providing input which would be more error prone than several people.

Afterwards we discussed some of the estimation techniques we use.  While some teams are doing planning poker, it seemed more were doing a relative ranking (still based around the Fibonacci sequence) on a wall with stickies.  The team determines an average story and then ranks all other stories as being easier or harder.

Another technique is to decouple the requirements readying, breaking down epics and stories and qualifying them to be ready for a Sprint.  This makes the estimation easier if an assumption is that the story will be ready.  Thanks to David Bulkin for introducing this technique at the 2010 US Agile Coach Camp.

Tere was one more discussion, but I am out of time for typing at the moment, so will add it later. 

To me, Agile software development approaches feel very natural.  It got me to thinking why…  I believe it may be because it has some similarities with what we experience in nature every day.  So this posting is to compare and contrast what feels natural in Agile.  While I recognize I am describing this in more or less an ideal fashion, it can help obtain some clarity by doing so.

What’s natural… 

Flows:  

Like streams, agile development flows to deliver value.  That value may be increased throughput of a process or an increase of sales, improvement in communications, or a myriad of other things.  

Even the lightweight processes we put in place are like flows.  Short feedback loops are like eddies in the stream.  Continuous integration is all about making this cyclical flow of feedback get shorter still.  Techniques like Kanban help us visual this flow, identify blockages that we need to keep the flow from backing up, and setting work in process limits help us make the flow continue smoothly.  

While some techniques or methods may seem more flow-oriented than others, I’d say that all of them try to identify and help flow become smoother. Whether it used only internally by the team to get feedback or to continuously create value, this usually comes down to emphasis only.  

Rhythms: 

In nature we see rhythms all around us, the rotation of the earth to give use the sunrise-sunset cycle, our heart pumps our blood with a regular beat, the regular change of seasons, and so on. 

Many of the techniques we use in Agile are to identify and help sustain team rhythms.  We have daily stand-ups to feel the pulse of the team.  We do regular just in time reviews and planning to help maintain the rhythm of work we are doing.  We measure velocity to understand if our cadence is being effective.  All of these is not necessarily about speeding up the rhythm of our team, though on occasions this may be desirable; it is more likely to identify, amplify, and understand what the team’s drumbeat is.  

The heartbeat is probably the best metaphor.  We look to ensure it is there, measure to know it is healthy, and when irregularities occur, we try to correct them as quickly as possible before they become detrimental.

Small Batches: 

Nature gives us things in small batches.  The weather gives us periods of rain intermittently with sunshine and plants produce fruits for only a short period.

In Agile, many of the ways we approach things are to also try and deliver value in small batches.  We attempt to demonstratively develop a small number of features that are ready for release.  Using restrospectives, we attempt to identify and implement a small number of improvements to help the team. 

Collaboration: 

Nature shows us many symbiotic relationships.  We’ll find remoras with rays or sharks for example; remoras help clean the sharks and the shark’s hunting provides the food the remoras need.  Sea anenomes will provide protection for the clownfish.  

In Agile, I identify this symbiosis as collaboration.   This could be our customers who provide requirements to the developers who build to these and demonstrate they achieved them back to the customer.  It could be the project manager (to use a generic term) that facilitates removal of barriers.  We use pair programming to ensure improve team collaboration.  We use techniques like team retrospectives to help us find ways to collaborate better.

Self Organization: 

In nature teams organize to overcome threats or work together to hunt.  The insects or animals in these circumstances collectively understand the goal, the sense of urgency, and the required communication.  There isn’t large upfront planning by one animal, though one may take a leadership role and commit with the rest joining in.

Likewise, Agile teams self-organize to deliver working software, resolve issues, or make plans.  In the ideal, this is done with as little ceremony and overhead as possible.  It will involve the entire team when it makes sense (e.g. planning an iteration) or the right members (e.g. pair programming) at other times.  When a major obstacle is encountered, the entire team will swarm until it is removed.

So if I am making a comparison to what is natural, it probably behooves me to look at 

What’s not natural…

Checklists: 

Checklists are used to ensure things get done.  While one may use this as a tool in self-organization, it doesn’t feel natural; this is particularly true after you have tried Kanban and in particular Personal Kanban.  Checklists feel overly simple and hide some of the complexities that need to be discussed.  They tend to fall under control of one individual, which works well if it is intended to be used by only one person.  If however they are intended to be used by a team, they tend to fall apart, as only  one person is usually placed in control of the checklist. Often checklists aren’t tailored to the context of the project at hand either.

I’m not personally against using checklists, but they don’t feel natural.  So I am suggesting just ensure that the context and environment is considered carefully. 

Sameness: 

In nature, nothing is identical; even identical twins aren’t truly identical.  Plants grow based on the environment; the same plant type may grow differently based on how much sun or water they get.  A stream meanders according to its terrain.

Software development is a craft. Craftsmen attempt to achieve perfection, but in context for what is being built.  Even a commercial off-the-shelf application packages (e.g. an office application suite like Microsoft Office) are used differently by different organizations; each are built to different goals.  

Contrast this with a manufacturing line; there if every item could be identical that would be a desirable process.  It would mean the process is producing goods within the desired tolerances.  

Big Upfront Design: 

And this probably the least natural.  Nature uses evolution to guide its designs.  Ants don’t lay out a huge plan to raid the picnic; they get sensory feedback, self organize, and attack.  Their planning is instinctive in nature and much like rolling wave planning.  Watermelon too big to move?  Bite and cut it into pieces for transportation.

Here is another example akin to rolling wave planning; evolution developed the sequoia trees to drop their cones around its base.  The seeds then start growing the young sequoias in a circle around the parent tree.  When the parent dies, it leaves a circle of trees called a druid circle.  This is a plan that as environment of the sequoias change they will slowly evolve to perhaps have seeds that are blown like maples, or roll, or a perhaps will become dependent on being dispersed by animals.

If you liked this article, please tweet it!

Tweet

The meeting held this past Friday was a little low in attendance (4 of us), but then in hindsight it coincided with Agile2010 and at least a few folks were on the road with that.

Anyway, we still had some great discussion around our theme of Retrospectives.  We started with a bit of just general discussion; Ken Mills let us know he’s now a Certified  Scrum Master - CONGRATS, and then we dove into two lightning talks that we decided would best be handled with a more open discussion format once the topic was introduced.  We only had a chance to discuss two:

Paul led a facilitation to show how the Triple Nickel exercise.  The Triple Nickel exercise is discussed in Agile Retrospectives by Esther Derby and Dianna Larsen and is a great tool for brainstorming.  It works by having 3 or more teams of people (2-4 usually) that write answers on a pad in a 3-5 min timebox.  They then pass the pad clock wise (or counter clockwise) to another group.  Then each group then has the same timebox again to add to or build upon the ideas passed to them from the prior group.  You do this one more time so that each pad has at least 3 group’s ideas and additions to ideas.  We decided to go around 4 times since there were 4 of us, starting with Ken M and we made the exercise on “what things make a good retrospective”:

Ken M started us off with the following: 

Detailed Agenda

Open Communication

Review of Previous Notes

Action Items with Ownership

Alex was next he added to the first one with Problems, Successes, and Solutions as the Agenda

Ken F then added some additional items:

 Just in Time (JIT); essentially focusing it on a “stop the line” mentality.  Realizing the urgency to improve is the gist I got.

Immediate Action - block off continuous improvement time immediately after. (We had some great discussion on how Ken F’s company provides time for people to do what they want and that perhaps adding in time to do nothing but improve would be both a strong motivator and a great way to improve productivity.)

Division of Labor - small manageable chucks of work and only review the work with the entire team

Pain Driven Development - this is the driver  for JIT; when a pain gets too great so that improvement is needed, then it’s JIT!

Paul added to the above with 

His detailed agenda is always the same and uses the flow from Agile Retrospectives: Set the Stage, Gather Data, Generate Insights, Analyze and Decide on 1-2 Experiments to take to improve, and then Close the Retrospective.

The review of the prior notes is a report out on the experiments taken based on the last retrospective.

And Paul changed the Action Items (which his team still often calls them) to Experiments.  This is to emphasize that if what is tried doesn’t help, there isn’t a knock on the decisions or implementation, but perhaps it wasn’t a good solution in the context of the team. 

The only addition was the use of dot voting when making any choices as it essentially builds a histogram of understanding. 

Hopefully everyone found practicing the Triple Nickel exercise a good way to evoke thoughts and ideas quickly. 

Ken Furlong led a discussion on Root Cause Analysis, which is one of the items at the heart of a good Retrospective.  Ken’s organization has a strong focus on root-cause analysis, so culturally they can do this without entering into the blame game.  They focus on details to include names and date-time when actions happen so that the true issue can be handled.

They start with a very detailed set of “pain” points.   What happened, when did it happen, who was involved, the conditions around the pain.  This is the problem.  An example Ken discussed was a call to a client by an account manager asking why the customer’s usage of their service dramatically decreased.  So an initial inquiry established the data was reviewed by this specific account manager first thing in the morning on a report.  The report was broken; the customer was truly using the service and happy with it.  The problem was it made the company look disorganized. So, the followed the information regarding the context of why the report was broken.  They find a DB table hadn’t gotten loaded properly.   They also find out that the report wasn’t tested properly.  They continue down both of those lines until they find out the root-causes.  

Also, though, they then discuss what caused or why did the account manager call?  The account manager called because he panicked when he saw the numbers.  Why did he panic?  Why didn’t he check with the IT department if he saw something incorrect. Why was he checking first thing in the morning?

Understanding both the technical and the human root-causes are considered extremely important.  

Paul mention that he had just finished reading Unfolding the Napkin: Solving Complex Problems with Simple Diagrams and they recommended covering 6 different items when both analyzing problems and recommending solutions:

1) Who & What? (the entities/objects)

2) How much?

3) When?

4) Where? 

5) Those lead to How?

6) Which then leads to Why?

Once you know the why, most of the battle to understanding how to fix it, then becomes easy.

We made a note that in order to a detailed WHO like Ken’s team can do means there has to be an awful lot of TRUST that it isn’t a witch hunt.

Some great discussion!

Our next AID meeting will be 5-7pm, 10 September, again at Argia’s in Falls Church.