Skip to content

Blogs

Green Goose

Tom Hume - Mon, 08/20/2012 - 13:52

Have you seen Green Goose? They're doing some beautiful stuff with sensors for consumers: turning everyday activities into games. I love the mundanity of it all: keeping the toilet seat up, brushing your teeth, walking the dog. One of their apps is called "BrushMonkey". It doesn't get any better than this.

They've been around for a little while - there's a story on RWW about them from early 2010, but they seem to have changed tack since then, away from financial monitoring and towards fun'n'games. Here's an interview with their founder from December last year. Green Goose seem to be spreading themselves thinly across many applications: "We’ve got about 50 or so other sensors in development right now that we will fairly quickly release over time".

Their hardware seems similar to Little Printer, in that they have their own gateway (the "station egg") which plugs into the spare port of a hub.

Categories: Blogs

Smart Interconnected Devices Hackathon

Tom Hume - Mon, 08/13/2012 - 14:53

If you're at all interested in this sort of thing, you might want to wander along to the Smart Interconnected Devices Hackathon at Google Campus this coming Saturday: a chance for Android developers to Plug Things Together in interesting configurations...

Categories: Blogs

Easy A

I have heard the car metaphor many times before – you know the one – “are we building a ford, or a ferrari?”. But that metaphor though has never really sat well with me – I couldn’t relate to it, and everyone always says “oh no, we are building a ford” and then proceed to describe the bells and whistles. Lately, I have started to look at other metaphors, and I have found one that is currently working for me.

At school, there were some subjects that I really wanted to do well in, and get As. Then there were subjects that I needed to take for prerequisites, but all I needed was to pass, so a C in that (or even a D) was perfectly fine by me.

When we develop software, there are some features that we really want to do well in and get right – these are our distinguishers. Then, there are other features that we just need to (e.g. to keep up with the market), but they don’t distinguish us from our competitors, so we want to spend only enough effort to get it in, without doing something distinguishing.

At school, there were also subjects that were basically easy As – I could put very little effort into studying for them, and I could take home top marks. Then, there also subjects that no matter how hard I studying, how much effort I put in, all I could pull off was a C.

When we develop software, there are some features that we can do really well at, for minimum effort. Then, there are features that are really trying to get in, and when we do, they might be a bit clunky or constantly requiring effort to maintain.

At school, there was also a limit to the number of subjects I could study at once. If I took more subjects then my normal limit, then they would all suffer – even the easy A weren’t so achievable. And I swapping between them all the time was difficult, so I would dedicate time to study on one at a time (usually half a day before I switched).

I think you can see where I am going…fill in the blanks about Work in Progress limits and “multi”-tasking.

So, thinking about stories and requests as school grades now gives a different perspective to prioritisation and valuing. We can start talking about getting outstanding As or just passing, about how some stories are easy to do well at (so let’s just do them) and others will take an effort to just pass (is that effort worth it in the end? Perhaps the time could be used for other features?). And for me, this metaphor is much more accessible – I have been there, I remember what it was like to study hard for subjects and get no where, and others be really easy and I remember prioritising my subjects based on how difficult it was (a really hard subject taken with an easy subject was the way to do it).

So – what grade would you like for that?

Categories: Blogs

Conferences: SDC and GoTo

I have been getting my speaking voice ready, and now I am getting set to use it. This week, I am speaking about how to integrate with other systems in my talk titled The Three Pronged Approach To Integrating Systems at Scandinavian Developer Conference 2011 in Gothenburg, Sweden. I am also running a conversation corner about feedback. If you want to follow what is going on, the hash tag is #scandev

Next month, I will be speaking at Goto CPH (in Copenhagen of course) in a talk titled What about People over Process? I am really looking forward to this one – the form is a little looser than I usually go for but it is an accumulation of all the psychology books I have been reading of late.

Categories: Blogs

Perfect Feedback

Marc Evers - Dreamfeed - Thu, 01/27/2011 - 21:41

One of my favourite tools for giving and receiving feedback is the Perfection Game. It is a powerful tool to give constructive feedback in a non-threatening way. It transforms feedback from an attack or personal judgement into a constructive act of jointly improving software, articles, conference sessions, blog entries…

The Perfection Game lowers the barrier for giving feedback. It makes it much easier for me to give feedback faster and earlier, and to ask for feedback. It is useful for any situation where you want to ask or give feedback in a constructive way.

The Perfection Game is simple, but not necessarily easy and not always well understood. So how does it work?

  • Someone presents their work, like a session proposal, a text, or code, and asks for feedback.
  • You (the reviewer) rate the work on a scale from 1 to 10, based on how much value you can add. 10 means that the work is perfect for you. In other words, 10 means you don’t see any way in which it can be improved.
  • You explain why you rated the work like you did. What makes up this number? What did you like about it? What should be kept?
  • You give concrete suggestions for improvement, i.e. actions that would make the work perfect.

An example of a perfection game applied to a session proposal is:

I would give this session proposal an 8 out of 10.

What I like about it:

  • catchy title, the abstract makes me want to attend
  • well thought out process, seems realistic for 90 minutes

To make it perfect, I would:

  • explicitly describe benefits for managers, because it would be good for the discussions to have the manager’s perspective in the room
  • make the link with agile development explicit, so that it appeals to a wider audience

Some remarks:

  • The rating is not a judgement, it is an indicator of how much possible improvement you see in the work.
  • The Perfection Game focuses on the work instead of the person; feedback is in the eye of the beholder.
  • Your improvement suggestions should be concrete and actionable; what would you do to improve the work?

It’s also great for perfectionists like me, to see the positive things and accomplishments as well ;-)

I’m co-organizer of Mini XP Days (1 April, to be announced) and XP Days Benelux (early December). We apply agile principles to organizing it, to make it an agile agile conference. We are feedback addicted and use the perfection game both during the conference, to get feedback about sessions, and in the iterative session review and improvement process, to help presenters develop quality sessions.

The Perfection Game is useful for any work product, code, text, design ideas, documents, blog entries, anything you are creating and you want to improve – it can help you get into a habit of constructive feedback and joint improvement, so that you’ll deliver better results faster.

So please do try this at home! (and work!) ;-)

Background information
Categories: Blogs

The fuzzy thing called lean

Marc Evers - Dreamfeed - Wed, 01/19/2011 - 22:22

I’ve been asked to do some presentations and workshops around lean and software development, which gives rise to some reflections on what’s currently going on around ‘lean’ (thanks to Willem for the good conversations on this topic and for pushing me to publish this blog entry ;-) )

Lean is becoming more and more of a hype, see people talking about lean methodology, lean certification, religiously implementing practices and tools like Value Stream Mapping, A3, Removing Waste (hey, I don’t like you you don’t add value, you’re waste!)

Lean is however not about practices & tools. It is primarily a philosophy, a way of looking at your organisation. Lean is about continuous improvement and developing the capability of the organisation and the people capability for improvement (see the Toyota Kata for more about this system that underlies lean).

Lean is inherently empirical, focusing on learning to see things as they are, not as they ought to be. Lean manifests itself in different contexts with different sets of principles and associated practices and tools. Lean works out differently for production processes, for services, for startups, for product development, even for software development there are different interpretations (listen e.g. to the Devnology interview with Mary and Tom Poppendieck)

I notice that a lot of conversations take place at the level of practices and tools, which are the most concrete manifestations. It is much easier to talk about tools, lean ‘methodology’ or even having a check list of observable lean practices. There is no general lean methodology, although different organizations can have a situated, continuously evolving methodology of their own, guided by lean principles.

Practices and tools are manifestations of principles and philosophy in a specific context – they’re specific solutions to specific problems in a specific context. They might or might not work in another context, even if that context is similar. But you won’t know if something works until you’ve applied it and got actual feedback from practice. This is related to what Dave Snowden writes about innovation diffusion:

Context is everything and often neglected. Something that works in one context may not work in another even if they are very similar. Ideas and practices need to have enough flexibility to adapt and ideally to combine with existing practice and other ideas. It means that pilot approaches have an inherent problem in that the initial success results in a specific context with a lot of effort. It won’t necessarily scale.

…and even when things worked out when you applied a practice or tool in your context, then you should be wary of confusing correlation with causation (doing the practice and having success does not imply a causal relation, it could be just correlation or even coincidence) and the retrospective coherence trap (everything looks logical and explainable in retrospect, but this does not help in predicting how things are going to work out).

Practices and tools are most concrete and easier to talk about, but they are the least important part of lean. They are highly situational,  almost random in a sense. To quote Dave Snowden again:

There is a paradox in that highly codified, highly abstracted material diffuses best (…), but is the least likely to be innovative or novel.

So people get stuck in tools, practices, methodologies, instead of focusing on philosophy and principles. The philosophy and principles are generative, setting up conditions that let a lean system emerge. Kanban for Software Development as presented by David Anderson and others is a good example of this.

Categories: Blogs

Excuses Might Be the Response, Not Necessarily Resistance

More Agile Than Agile - Fri, 03/05/2010 - 19:41

I had an interesting conversation with a manager the other day about how to gain more insight into changes that are ongoing in the application one of our pilot Scrum teams is working on.  First, what’s the problem?  Group A was doing independent regression for a release and uncovered some ”defects’ that were a result of changes in the application by our Scrum team.  Truth be told, those ‘defects’ are actually de-commissioned functionality.

Manager:  We need to know what’s being changed in the application, we can’t be chasing down defects because of changes we don’t know about.

Me:  Agreed.  We’ve extended the offer for you to come to our end of iteration demos and until this week we haven’t made any changes in existing code so I agree, with these changes we’ll have to invalidate some of the old regression tests that aren’t needed anymore.

Manager: I don’t have time for that.  Is there some type of documentation about the changes?

Me: Yes.  We’ve started using javadocs to document the code and our functional information is in Rally.  Brief, but explains the functionality well enough.  The team members would easily be able to figure out the impact of the changes since they all know the app well enough.

Manager:  I can’t ask my team to waste time sorting through Rally to find this information.

Me: We can export a list for you and email it, it’s a 4 or 5 column XLS with a good summary.

Manager:  Do you know how much email we get?  I can’t agree to that.

Me: Ok, how about you and the members of the other groups who need insight into the changes come to our demos?  We do a 15-minute quick overview before digging deep into the stories we completed.

Manager: They can’t do that, we don’t have approval from their managers to go to your demo.

Me: Ok, we do send a summary of what’s being updated when we make our iteration commitment and we send a summary output after the iteration demo, I can include you on those.

Manager: There’s too much to do, I have to worry about this project, that release, aligning this team with that team, I get too much email now, we need a process.

Me:  Ok, so how about we just have the people from the other groups attend our demo, we’ll give them the 15-minute overview and send the summary of changes before and after the iteration.  If we need to do a more in-depth session, we’re happy to.

Manager: I’ll go talk to the managers to get permission for the other resources to go to the demo.

Me: Great, that should make it easier and really efficient to share information between our Scrum team and the waterfall and regression teams. Thanks!

At the end of the conversation we were right back to where we started.  A quick and efficient session to share knowledge with the people who are programming or testing the software.  I had continued this conversation with a few folks to get to the real problem and the challenges being faces are typical.

So what’s up with all the excuses?  Did we have to fill up the 30 minute time-slot for the meeting to be effective?  I decided to dig deeper:

Q1) Why was the initial response that people couldn’t spare 15 minutes every 2 weeks to get visibility?

A1) Because we are too busy.

Q2) Why are we too too busy?

A2) Because regression testing takes 3 weeks.

Q3) Why does regression testing take 3 weeks?

A3) Because our testing is manual.

Q4) Why is our testing manual?

A4) Because that’s how we do it.

Q5) Why do we choose to do it that way?

A5) Because there are too many projects and we don’t have time to do it another way

I’m sure there were a couple more excuses tossed into that first conversation, I started losing count but the underlying problem of having too many projects in progress at a time are causing a whole host of downstream problems.

At this stage, portfolio management isn’t something we can focus on, especially in a large and complex organization.  First step is to create visibility to outside teams and trim down the regression suite so there is less waste with manual testing.  Our team has already started looking at automating end-to-end regression for happy path scenarios which will also reduce the amount of time spent on manual testing.

It’s a small step, but we need to start somewhere but the message in this post is that things aren’t always as they seem.  The initial response is often a gut-reaction based on stress or other factors and it shouldn’t be confused with resistance to improvement or efficiency gain.

Categories: Blogs

Learn the Secrets of Collaboration…From Your Kids

More Agile Than Agile - Wed, 02/24/2010 - 20:45

One of the simulations I like to facilitate during training sessions is a simple penny flipping exercise learned from Mishkin Berteig to show how the team approach can lead to substantial improvement and productivity gains.

The idea is simple, have the attendees work in a serial process where they have to pass the penny from person to person.  The goal is to get the pennies facing heads up in ‘the product environment’ (which is a piece of paper) at the end of the chain.  The second part has the same goal, but the teams can accomplish it however they want. I usually repeat the second part a couple of times to prove the meaning behind the exercise.  I’ll add a post with the mechanics on this game later.

Anyway, last night my 2 kids and I were playing dominos which always results in a living room disaster since we have a few hundred of the them.  20 minutes for me to set them up, 10 seconds for them to knock them down.   When it was time to clean up I simply stated the goal.  ”Ok guys, time to put all the dominos away in the clear bin“.  Just like a high-performing Scrum team, we started singing the Wonder Pets Teamwork song (what’s gunna work?  TEAMWORK!) and each “team member” started cleaning up.

My 4 year old son started picking up the dominos nearest to him, same for me and my 3 year old daughter.  The bucket was pretty much centralized between the 3 of us.  After we had cleaned up the dominos closet to us, my son immediately took the bin, moved it to the next ‘batch of mess’ and we proceeded to start with whatever dominos were nearest to us.  My daughter had walked towards the pile my son started with so she quickly self-adjusted and started on another pile.

I was stunned.  The collaboration was completely instinctive and there was very little, if any, discussion.  We all knew what the goal was and we all chipped in.  Once there were only a handful of dominos left, all 3 of us focused on that so no one was idle until there were less than 3 dominos left.

Sounds silly, I know, but the Agile principles were were much apparent to me during this clean-up session:

  • all team members understood the goal
  • team members self-organized
  • team members adjusted based on work remaining
  • team members started with highest priority items (as in, we all started with the pile in front of us)
  • we had fun while working! (For those who don’t have kids, trying to convince a 3 and 4 year old to clean-up is not really that easy most of the time!)

I often get complaints in training sessions about the simplicity of the exercise and that moving pennies is different than real-world work.  I agree, it is but applying the one-team, shared goal value is more important.  Once folks buy into the team system, the rest of the work falls into line much easier.

Categories: Blogs

Proper and Improper Use of CMMI

Agile CMMI blog - Wed, 02/03/2010 - 00:44

Just a few thoughts on some questions to pose as a sort of “guide” for whether or not you might expect benefits and value from using CMMI.  These also have the benefit of helping CMMI be implemented in a more lean/agile approach.

When implementing CMMI, Are you seeking . . .

  • Improvement or Compliance?
  • Empowerment or Definition?
  • Clarity & Awareness or Constraints & Rigidity?
  • Bottom-up input or Top-down direction?
  • To understand whether what you’re doing is working?  or Whether you’re doing what the process says?

In this case, we also value the things on the left more.

:-)

The things on the right are a longer road, with questionable benefits and many risks.  The things on the left get you to benefits and value sooner with less carnage and baggage.

Take your pick.

Categories: Blogs

Simple Exercise to Demonstrate Value of Collaboration

More Agile Than Agile - Thu, 01/28/2010 - 21:08

This is a quick and simple exercise I ended up doing ‘off the cuff’ but based on feedback from the class, had huge value that talked about why the conversation is the most important piece of the user story.

I focus heavily on making the point that the written word is less important and while INVEST shows us there are good ways and bad ways to write stories, the disconnect is always a result of lack of communication.

This exercise takes Mike Cohn’s “entree comes with soup or salad and bread” statement from his User Stories book and allows small groups to write down what they are giving me when I order that in a restaurant.

Tools required:

- whiteboard or flip chart to record the responses
- a few sticky notes or paper for the small teams to write on
- pens
- play-food could be optional to make it more fun!

Set the Stage:

Have the group split into small groups of 3, depending on class size.  I had 3 groups of 4 in this particular class.  As product owner, I want to order the entree with soup or salad and bread but I have to run to another meeting, I expect to get what I ordered by the time I get back.  You can leave the room, but I stayed in the room to hear the type of conversation that is happening.

Timebox: 5 minutes (up to you I suppose, I figured that was reasonable)

Expected result:

- ideally you will get at least 2 different orders.  In this case, each group gave me 3 different orders which was perfect to demonstrate the value behind the exercise

Observations:

- immediately I heard conversations like “what did he mean?  does he want soup or (salad and bread) or (soup or salad) and bread?”
- didn’t hear conversations like “we can’t do this until we can ask him what he wants to clarify” – all 3 groups just decided to guess and hope for the best

Learnings:

- the conversation is the most important part of the user stories’ 3 C’s.
- focus on the conversation, not the text in the story
-  the conversation to clear this scenario up is 1 minute or less as opposed to the effort required to revamp the documentation, then update the story in your tool
- business people and developers MUST communicate daily

I just thought about this as the class was starting so there was zero prep or thinking, just figured it was better than me blabbing on and on about why people should talk to each other!  I plan to try this exercise again, the feedback from the group was unanimous.  They all ‘got it’ that the point of the user story was the conversation.  I start each class with a focus question and this exercise quickly answered about half of the responses.  Most were concerned about the story missing details, how can I write better stories for the team etc.

Would love to hear your thoughts!

Categories: Blogs

People over Process . . .

Agile CMMI blog - Sun, 01/24/2010 - 22:41

The agile manifesto makes clear the authors’ value of people over process.  With that, many readers/users of the manifesto somehow misconstrue this as “People.  No process.”

Others, being more intelligent and reasonable, do see the value of having and using processes, they’re thinking a little beyond the next 11 seconds and are reflecting a bit deeper on the roles of and interplay between people and processes.  Such people are seeing that the real question isn’t about people or process, but that what they struggle with is how to find value in what people do and the processes they perform.

Value.

That’s a powerful word.  I love this rich word.  You can get all sorts of people to stop and think about what they’re doing when you ask them the value of their effort.

Asking about value can come full circle – even for process people.  What’s the value, for example, of checking on a process?

Many use process audits, but what’s the value in it?  Especially if the process works fine, and, there’s a cost to check on it – with a net result that you spent time (= money) checking for something that didn’t and might not happen.

Calling them “objective evaluation”, CMMI® is replete with efforts that are expected to check on processes.  (GP2.9, PPQA, OPF, et al.)  Though, CMMI® is purposefully thin on exactly how to accomplish this, many have chosen to carry out “objective evaluation” using ‘audits’.

Audits not only invoke a confrontational and defensive entrenchment, but also have the attribute of easily devolving into “process policing” and other non-value-added paradigms.  Don’t misunderstand, we’re not saying it’s not important to keep tabs on your processes, but there are more and less value-added approaches to how you go about doing them.

At the risk of sounding too much like advice from an Eastern mountain top, I propose that you allow people to be the process.

That is, imbue a cadre of people whose jobs are to know the processes best.  Not CMMI® processes, not Agile practices, but the processes the organization wants everyone to know and use.  How else will anyone know what to do?  Great organizations do this all the time.  No one questions their use of such people.

Clearly, it would be out of character for me to suggest that you don't have processes, or that you create “lottery sensitive positions” (i.e., critical, single-point-failure positions whose loss would be severely disruptive to success).  So, this is not what I’m saying.

But if the idea is that you want everyone to be on the same page, that you want to create processes that people want and love and that they can identify with;

if you want to create a reliable culture of excellence where everyone truly participates in creating exquisite results;

where everyone is fully invested in the organization and its success;

in the language of CMMI® -- where the processes are firmly institutionalized;

that people who know the process very well and whose jobs are dedicated to helping everyone else learn and use the process are out in the projects coaching and mentoring teams in the process, facilitating retrospectives, demos, peer reviews and whatnot...

There isn't a non-CMMI® or a non-Agile thing about this!

We’re talking about coaching, mentoring, and facilitation.

Self-directed, self-organized teams still have coaches, Scrum masters, and someone to turn to when things are stuck or just don't seem to be working correctly...

... you want to grow an organization where everyone knows what to do without being told?  Use coaching and mentoring of your patterns in your patterns

There can be a smaller organization of just such coaches, mentors and facilitators, with others rotating in and out of on some regular cadence, these people can also gather lessons, collect information, spread new ideas, create experiments, and routinely check to see whether and how well what teams are doing is working. 

If/when there are new and better ways of doing things, these coaches can help refine them and make them usable by other teams, when things are broken, they help fix them. 

Why do audits want to know whether the process is being followed?  If it’s compliance, then it might very well be a waste of time. 

The real reason is to learn about the process and to use the audit as an opportunity to learn about and share what’s working and what doesn’t.  So, instead of audits, why not jump straight to the real purpose behind them and ask, “what are you doing?” and  “how’s that working for you?”

You’ll get the same benefit without all the baggage, waste and negativity.

Doesn't everyone know this is what having a defined process is?

Doesn't everyone understand that this is how process evaluations or audits are supposed to work? 

No?  Really?  Huh!

People over Process, Right?  Great!  Let people *be* the process!

Categories: Blogs

Position Paper for Agile Coach Camp 2010

More Agile Than Agile - Thu, 01/21/2010 - 05:43

Agile Coach Camp 2010 is coming the weekend of March 19, 2010 in North Carolina.    I’ve heard great things about Coach Camp and this is my first opportunity to attend.  You can check out their site here and for those who aren’t familiar with Coach Camp, it’s an Open Space conference focused on peer-to-peer learning and exploration as opposed to the traditional speaker/audience conferences I’m not a huge fan of.

Anywho, onto the position paper:  You’ll notice these are high-level points, that’s the point of Coach Camp.  The goal is to share experience and gain feedback from the Agile community.

Title: A Recipe for Enterprise Agile Transformation

Background and Challenges:

  • large department within large organization
  • tall hierarchy, great deal of office politics
  • heavily silo’d organization
  • complex product portfolio
  • mix of full time, contractors, outsourced developers and teams
  • limited people with Agile experience in the organization
  • no recognized Agile champion

Speaking and Presentation topics I plan to share:

  • transitioning focus of functional managers and other roles
    • there is much confusion about ‘where does my role fit’?
  • breaking down silos between multiple groups
    • having to prove you are worthy of being trusted
    • demonstrating and sharing success and failures
  • portfolio and team organization
    • how to structure your teams with the right skills for the project
  • techniques for handling ’specialist’ groups
    • how these groups interface with teams
    • how these groups share information gained from working with multiple teams
  • cross-project knowledge sharing (technical or process related)
    • getting people together to talk about experiences.
  • How PMO and process teams evolve
    • more teaching and coach, less command and control
  • spreading Agile culture
    • making it about the organization, not the coaches
    • teaching the organization to think for themselves

The above topics will be accompanied by some fancy diagrams I’m working on for an experience paper and due to the format of Coach Camp, if my paper is accepted and put into the plan, the topics discussed with likely be determined by what my peers want to hear about.

I am still planning on writing and experience paper I had hoped to have finished by now where I can share more details.  Interested in your thoughts and experiences!

Categories: Blogs

Do you have what it takes . . . ?

Agile CMMI blog - Sun, 01/17/2010 - 23:09

To pursue CMMI and/or to reap the benefits of agile requires more than just desire at the working level.  It takes:

  • honesty
  • learning
  • transparency
  • respect
  • support
  • trust
  • patience
  • commitment (to excellence)

Not just from people who will feel the changes most immediately but from the top-most person in the company on down to those people whose work support the people who will feel the changes most.

If you have an executive who declares: we want "maturity level __” by such-and-so date, and doesn’t themselves bother to take the time to understand what that means, you don’t have what it takes.

If you have an executive who declares: we want "to be more agile” but doesn’t allow developers to organize their workspace or their time, you don’t have what it takes.

If you have an executive who doesn’t care how negatively a drastic poorly considered change will impact the developers, you don’t have what it takes.

If you have an executive who expects everyone but themselves to change or expects that hiring an outsider can eliminate the hard work needed to move from the present situation to the desired state, you don’t have what it takes.

Might I recommend this course for getting to know CMMI, at least.  It can be attended in person or on line.  Live.

Categories: Blogs

Waterfalling your Iterations: Not the way to handle re-work

More Agile Than Agile - Fri, 01/15/2010 - 20:14

Ah, good old re-work.  The thorn in the side of Scrum teams, the impossible mountain to climb for development teams.  Re-work is un-avoidable.  When people see working software, they get new ideas and might want some changes.   Here are some thoughts for handling re-work based on a few scenarios that popped up at work this week.

If We Knew Earlier, We Coulda Did Something About it

Situation: During our iteration demos the team I’m working with found that they had improvements and suggestions now that they could ’step back’ and see their work.  Other folks who we invite to the demo would have some small ideas or our Product Owner would have some suggestions that were nit-picky, but nonetheless would be better for the user.

Problem: Waiting too long to get feedback.

Solution: I’m happy the team came to this conclusion themselves in the retrospective.  One of the team members posed the question that why don’t we show our product owner immediately when we complete the story and not wait for the demo?  Side note: I’ve mentioned this to them a few times, but it was great to see them take a problem and apply the learnings on their own.

Splitting the Iteration into Work and Re-work Phases

Scenario: There is too much re-work at the end of the iteration so we are going to take our 1 week iterations and shorten them to 3 days so we have 2 days to do re-work.

Problem: too much WIP and lack of communication between team and product owner. (In this scenario the product owner isn’t available full-time to the team and the proxy he assigned can’t always make a decision). There are a few other things happening here as well.  The work this team does is non-software and they rely frequently on interacting with people in other departments.  They’ll start something, get blocked and move on to something else therefore creating a great deal of waste.

Solution: The team has been struggling with this for a few iterations, I’m not working with them but did have a chat with their Scrum Master since he felt it was a failure on his part.  Not so at all.   I told him maybe trying to hammer Scrum into their work-style wasn’t the best thing to do.  Perhaps a Kanban system would be more effective for them.   We talked about what that meant and they’re not ready for that so instead they’ll try communicating with the product owner more often and help the PO understand he needs to be available for the team to fulfill their commitments.

Agile/Waterfall Hybrids is What we Did!

This one came up in a training session I was doing.  One of the attendees said mixing waterfall and Agile can work because in his experience there was no way to handle re-work in Agile.  The solution to this is similar to the first scenario I discussed at the start of this post.

The root of this problem is not getting feedback early enough or the lack of daily communication between the Product Owner and the Team that is required when using an Agile process.  A deeper problem was the apparent separation between programmers and testers on the team he was talking about.  I wasn’t able to deep-dive into the scenario since it was in the middle of class but I offered some suggestions about why it might be happening.

All of these examples, in my opinion, are some of the main reasons why companies fail with Agile.  They interpret “Agile” to mean flexible and let’s just change the rules to make it work for us.  While Scrum is a simple, adaptable framework, the fundamentals shouldn’t be changed to accommodate a broken process.   This type of dysfunction can lead to mis-trust between the Team and the business and also cause a rift between programmers and testers as they will start to ‘fall back’ into a waterfall mentality.

It’s important that the Scrum Master or Coach help the teams struggling with this to understand what the real underlying issue is and to work through it.

Categories: Blogs

Contextually Relevant Experience & Why It Matters

Agile CMMI blog - Sun, 01/10/2010 - 16:40

Imagine what would happen if you went to a doctor (or any specialist) who had no experience in your specific condition or situation.  Has this every happened to you?  It has to my family when I was young.  Let me tell you, it wasn’t pleasant.  What was frightening was that the “professional” didn’t know that they didn’t have the right experience.  What was just as bad was that my family didn’t have the knowledge or experience to know that the person we went to was not qualified.

This is a situation encountered by many organizations when seeking advice and/or appraisal services from a CMMI consultant / appraiser.  However, in business, you should at least know enough about your organization and ways of operating to do your homework before picking someone to help you with CMMI.

What you may not have known is that CMMI and the appraisal method are not as clear and obvious as other means of performance evaluation and that you must choose your consulting firm and appraiser very carefully, and among other factors, consider their contextually relevant experience. . . .

Categories: Blogs

The Agile Coach Manifesto

More Agile Than Agile - Fri, 01/08/2010 - 21:36

The Agile Manifesto is the heart of soul of what it means to be Agile and I often refer back to when talking to colleagues and especially with those that are new to Agile.  This post was sparked after a great cross-group meeting that happened yesterday where some information was shared between groups that typically wouldn’t have otherwise collaborated.

I had been asked to present a quick talk on Scrum for a couple of new teams that will be starting up soon, followed by a quick overview of these new projects.   The output of this session coupled with what I learned at AYE and through the weekly coach round-table I attend with Michael Sahota, Gerry Kirk and Declan Whelan (special thanks to Michael Spayd for his recent ‘guest appearance’!) gave me some inspiration to write this.  I hope it is of value to you.

Client Success over Personal Gain:  The Coach isn’t the hero.  They are there to help the organization.  They need to understand the client and contribute to their success, without worry about accolades or personal gain.  This includes the coach fulfilling his duties to the best of his abilities instead of holding back to extend the gig.  I like to take the approach that my goal is to work myself out of a job as efficiently as possible because the organization needs to be self-sustaining to succeed.  Others will argue that “well, I need to make a living” but I knew the risks when I took this path.  If I’m any good I’ll find more work.

Guiding over Dictating: Resist the temptation for the ‘my way or the highway’ approach, especially in organizations that have a more controlling culture.   Organizations need to learn and they learn the same way a team learns, through experimentation.  A coach needs to help guide them to the answer because the people in the organization are best served to find these answers with the help of a coach.

Objectivity over Subjectivity:  The coach needs to remain agnostic in order to avoid making emotional decisions.  I do get frustrated when my observation is that the client isn’t listening but that just means I’m doing a poor job of communicating. Remain clearly focused and you will serve the client better.

Adaptation over Doing-What-Worked-Last-Time:  Ok, so this one is the same as ‘Responding to Change over Following the Plan” however I mean that organizations are unique.  What you were successful with at your last gig won’t necessarily translate into success at your current gig.   To me, this one is about understanding the organization’s culture so you can frame your approach.  Controlling cultures will require a different approach as opposed to collaborative cultures for example.

I firmly believe it’s the responsibility of any coach to make sure the Agile transition is about the client.  Deflect focus from being the expert and help the organization understand that Agile is a tool and it’s only as good as how it’s used by the people using it.

Categories: Blogs

Love & Marriage: CMMI & Agile Need Each Other

Agile CMMI blog - Wed, 01/06/2010 - 14:10
An article in this month's CrossTalk periodical, is now out.1001FrontCover-300

See it here.

Download it here .

Enjoy!hg_signature_blue_FNAME

 

 

 

 

P.S.  There are other great articles in the issue as well.  I'm in great company with an article by my friend, colleague and client, Jeff Dutton.  And, don't miss out what's coming next in v1.3 from my buds Mike Philips and Sandy Schrum!

Categories: Blogs

4 Steps to an Agile Transformation

More Agile Than Agile - Thu, 12/31/2009 - 18:25

I often find that people new to Agile have a tough time understanding that Agile processes are empirical and there really isn’t a one-size-fits-all model that will work for every organization.  Scrum, XP, Crystal, Lean and other Agile methods all have their practices that provide guidance and tools but none of them are going to tell you the recipe for success.

This is one of many reasons why hiring an Agile Coach is a good idea.  A good Agile Coach will practice what they preach and use these same methods to help with an Agile transformation.  If we are talking the talk, it’s probably a good idea to walk the walk.  For starters it shows you’re passionate about Agile and it proves you know the tools and how to apply them.  It’s also a great opportunity to lead by example.

There is responsibility and “do’s and don’ts” on the part of the coach and the organization to work together towards an Agile transformation.  Below are 4 simple steps with some tips that can serve as a guide for how to approach an Agile transformation.  Again, there is no one-size-fits-all approach but there are some basic fundamentals and common sense practices I have found useful that I wanted to share.

Understand: How do you know if you need a hammer for the job if you don’t understand the task in front of you?

Coach:

  • understand why the organization wants/needs to adopt Agile practices
    • are they concerned about quality?
    • is their business in jeopardy and they fundamentally need to change how they operate?
    • are they simple tired of the status quo?
  • understand the current state of the organization:
    • how the organization is structured?
    • where is the support for transforming to Agile?
    • what’s the skillset like?
  • understand that the Agile transformation is about the organization, not you

Organization:

  • understand that an Agile transformation is more about a culture change than an adoption of processes and tools
  • understand that Agile is not a quick fix
  • understand the an Agile transformation is costly and time-consuming
  • understand that ALL levels of the organization need to be involved
  • understand that you will not like some of the answers you get from your coach

Educate: This is important.  I find that often people just want the answer.  A good coach needs to educate the organization so they can apply that knowledge instead of giving them all the answers.

Coach:

  • teach the 4 values
  • teach the 12 principles
  • conduct workshops that help the organization understand the meaning behind the values and principles
  • make it fun
  • Educate them on the use of the tools (both thinking and software tools) you plan to use based on your understanding obtained in step 1

Organization:

  • be open to learning, don’t dismiss the education because “it won’t work here
  • reject the status quo,”look around, it doesn’t need to be this way” – Gerry Weinberg
  • challenge and question the education, don’t simply accept everything the coach teaches, challenge those teachings to make them work in your environment.

Execute: Now the hard part.  Agile is easy, implementing Agile is very difficult.

Coach:

  • start simple, you should understand how much of a shock the transformation will be, a simple approach may be best
  • the organization will not always listen to you. You will serve the organization better if you can remain positive and objective
  • collaborate with the team(s) and/or organization instead of giving them all the answers
  • learn to ask powerful questions to help them relate the 4 values and principles to daily work
  • refer back to the values and principles often, this helps drive the organization to think and apply these values and principles
  • start internal user groups, blogs, wikis, get collaboration and discussion happening, spread Agile culture

Organization:

  • remain optimistic, you will be frustrated at times but stick with it
  • embrace uncertainty ” – Jeff Patton
  • expect to experience failure, but remember to learn from it
  • it might sound crazy, but it just might work.  Give it a shot.

Reflect:  Use retrospectives extensively, and not just with the team(s).  Retrospectives will help the teams with daily ‘in the trenches‘ work and they will help management and executives inspect and adapt on their transformation plan.

Coach:

  • this is a tough one, but be honest with yourself.  Are you the right coach for this organization? Do you need help?
  • based on organization feedback, add new tools and practices as necessary to support these new learning opportunities
  • help the organization learn how to improve in small increments

Organization

  • try not to get overwhelmed, Agile tends to expose problems very quickly – use reflection to make small, incremental improvements and try to avoid the big-bang solution approach
  • be honest with yourself, don’t ignore the problems that surface, attack them

Rinse and repeat often.  These 4 steps are cyclical.  Reflection leads to a greater understanding which leads to new learning opportunities that will likely require different tactics during execution.

Categories: Blogs

Picking a Lead Appraiser: "Dammit, Jim! I'm a doctor not a bricklayer."

Agile CMMI blog - Sun, 12/27/2009 - 16:26

In this quote, CAPT Kirk wants Dr. Bones McCoy to do something he feels he's not-qualified to do because he doesn't know how to treat the species.   

I'm using it to explain that organizations looking for a lead appraiser to work with them towards an appraisal and/or to perform an appraisal ought to think of what we do as they would think of a doctor, not a laborer or vendor. 

Do you really want the lowest price doctor?

For that matter, is the highest price doctor necessarily the best in town?

When reaching out and interviewing for a lead appraiser or CMMI consultant, you:

    • Want the person who is the right person for the job.

    • Want someone who is qualified (definitely not under-, but preferably not over- either).

    • Not the lowest bid.

    Seriously, whoever you hire for this effort has in their power the ability to make or break your future.  They literally have the health and well-being of your organization in their hands.  They can put you in the dump just as easily as they can take you to the next level.

    They should see themselves that way as well. 

    Unfortunately I've got too many sad stories of appraisers/consultants who definitely see that they can make or break you, but they don't feel like they personally own the responsibility for what happens to you when they're done. 

    If it costs too much?  So what?  
    If you get no value?  Not their problem.  
    Didn't see any benefit?  Didn't learn anything?  Things take longer and cost more and you're not seeing internal efficiencies improve?
    YOU must be doing something wrong, not them.

    In an AgileCMMI approach, your CMMI consultant and/or lead appraiser would see themselves as and act like a coach, and would put lean processes and business value ahead of anything else.  And, an AgileCMMI approach would know that when the processes work, they add value; when they add value people like them and use them; when people like and use them, the next “level” is a big no-brainer-nothing.  You get it in your sleep.

    Let me know if you want help finding the right lead appraiser or consultant.

    Categories: Blogs

    How to Give Great Feedback

    More Agile Than Agile - Wed, 12/23/2009 - 22:08

    What I really enjoy about being part of the Agile community is open communication and willingness my colleagues have to learning and self-improvement.

    I’ve been fortunate enough to interact with some wonderfully brilliant people and a keen observation I’ve taken away is how these folks give feedback to fellow colleagues.  The flip side is that when it comes to a manager/employee relationship, very few managers I’ve worked with have this unique skill.    I’m quite sure there are some great books on how to give effective feedback (actually, please add some to the comments…I’d love to read some) but I’ve been on the receiving side of enough generic “great job!” comments to know what people truly find appreciative when receiving recognition.

    Be Specific.

    While praise has it’s place, there is no substitute to providing concrete examples of WHY you are appreciative of someone else’s efforts.  When I give feedback to team members, employees or direct superiors I make sure to provide them with specific examples of why I appreciate them.  A recent example was feedback I gave to a co-worker who is not part of the team I’m working with.  This person provided support to our team and also willingly participated in a couple of estimation and planning sessions because the team needed his help.  I made sure to state my appreciation that, although he wasn’t part of the team, the team experienced success because of his help at key points in project.

    Another side effect of being specific is that your feedback will be more honest and the receiver will be more appreciative because they will know you aren’t just blowing smoke.

    Categories: Blogs