ardonio.com

Retrospectives

Posted on April 18, 2012 by Don Ardonio

A retrospective, as the word suggest is where you look back at events during a certain period of time. In Scrum terms ‘period of time’ often comes down to ‘iteration’ as it provides a nice clean ending to it but it’s not strictly necessary in my opinion. Mostly, I want to talk about the content of a retrospective and why I think it is one of the most powerful tools available…and as always, with great power comes great responsibility.

There are a large number of ways to moderate a retrospective but all of them come down to looking at 3 things related to the process. It’s about what went well, what didn’t go well and what changes you will make to improve. The most important bit of that is that it’s about the process and the way the team works. This is generally not the place where detailed technical discussions are held.

So first of all, why would you talk about what’s going well? The answer is simple. Because it is important! Knowing what the team thinks is going well is not just about morale, it also tells something about how the team is organized and what style they prefer. This might well be one of the best guidelines to use for future improvements, yet it’s often dismissed as just a pat on the back.

Secondly looking at what the team doesn’t like. Most people find it easy to come up with a list of things that irritate them in one way or another, or that they want to see changed. Most scrum masters have learned to group those issues and push for solutions, so I won’t go into that. What I think is an equally valued piece of information from this is seeing how the team matures in understanding/using a process. As the team works more and more with your Agile method of choice, you’ll find that the topics for improvement start digging deeper into the core of the process. Where most young teams focus on the technical bits of the project or on some fairly superficial aspects (let’s say the colour of the cards on the board…I kid you not, I’ve been there) the mature teams will ask for fundamental changes to the process. As a scrum master you should be keeping an eye on this evolution to understand how close to the “base process” a team can (or should) stick while still performing well.

The last point is the most important one. Finding ways to improve on what isn’t going well. If you don’t do this it’s fair to say that your retro was wasted (apart for the psychological venting aspect perhaps). Most teams have suggestions of what to improve and often a pretty good idea of how to achieve that. In light of the maturity of the team and the way they prefer to work, as a scrum master you should be able to find a solution. So far so good. The thing that is often forgotten is to also define how you are going to follow up if there is really something improving. I’m not talking s.m.a.r.t. goals here, but there should be a measure or means to track if your solution is in fact making life better. And the next retro should ideally start with just a quick recap on the actions taken to ensure things are in fact improving. Inspect, adapt…and inspect again.

So, summing it all up, the good is great for understanding your team’s preferences, the bad is a measure of maturity and don’t forget to follow up on changes you make. And for those customers who don’t believe a retro adds value…compare it to changing the oil in your car’s engine. You can keep running without changing it and hope all goes well until suddenly your entire engine is ruined, or you could regularly check and make sure all keeps running well. Your call…

Share and Enjoy:

Posted in agile, kanban, leadership, scrum | Leave a comment

Velocity

Posted on January 28, 2012 by Don Ardonio

“When will it be done?”… that, or a variation thereof, must be the question I hear most from customers. No customer really wants to know “How complex is it?” or “How much technical debt did you incur?”…even if they ask that kind of questions, what they really want to understand is when it will be done. So whatever measure we introduce, its purpose should be to answer that question.

Storypoints

Velocity seems to be logical answer as it is clearly a measure of (past) progress and by extension a means of projecting future progress. Often it is defined as storypoints per iteration. We all understand ‘iteration’ so let’s focus on ‘storypoints’.
Unlike velocity, storypoint doesn’t really come with a commonly accepted definition. From team to team it ranges from the fluffy side of ‘measure of complexity’ and ‘how much coding is involved’ to a hard ’1.6 days’. In my opinion it’s none of that and all of that. Storypoints are a means of expressing how one task compares to another in terms of what it takes to getting it done. This means that complexity, uncertainty, knowledge and skill are definitely part of that idea, but equally so is the time you need to complete it.
I’m not sure where I read or heard it, but someone once made the comparison between licking a huge amount of stamps and putting them on an envelope and a brain surgeon performing a ‘simple’ surgery. Even though the brain surgery definitely carries more risk and complexity, the stamp task would be the same amount of storypoints simply because of the time needed to complete it. I admit there are a number of flaws with that example, but from understanding a storypoint angle, I think it works rather nicely. Some teams have a set of measures for a story like ‘complexity points’ and ‘size’, my advice would be to not overcomplicate it and roll all that up in one estimate: storypoint.

Understanding Velocity

Now we’ve settled that, let’s go back to velocity. It becomes a measure of “some amount of what it takes to getting it done” per iteration, but what is included in that ‘some amount’. By and large there are 2 opinions on that front.
The first is one that says only new work should be estimated in points. In relation to my post on defect handling, that would mean that bugs of type 1 and 3 are not included in this.
The other option is that everything is estimated with storypoints. In the defect handling post, that would mean that bugs of type 1 and 3 are storypointed and the % of slack in a sprint is also represented with a storypoint value.
The impact on velocity is that in the first situation velocity becomes a measure of ‘forward’ progress. I.e. how much new stuff can we do in a sprint. In the second, velocity starts representing a more true measure of productivity (in the sense of stuff that got done over time).
Neither of those is more right or wrong than the other, it simply is a matter of understanding what you are measuring.

Purpose, measures, methods

I can’t close this article without bringing in one of my favorite topics: methods follow measure follow purpose.
All too often I see certified idiots who claim that velocity improvement is the purpose and who believe that as long as their velocity improves they are ‘doing it right’. I guarantee that whenever I hear one of those, a puppy dies a horrible death in the fires of mount doom. The goal shouldn’t be to achieve a higher velocity, the goal is to get things done and get them done right. Velocity is nothing more than a measure that helps you understand how you are doing. And as a consequence your methods shouldn’t focus on getting your velocity to some arbitrary level (let alone that ‘targets’ are tied to velocity) but your focus should be on how much you got done.

Share and Enjoy:

Posted in agile, scrum, Uncategorized | Leave a comment

Defect handling in an Agile approach

Posted on November 27, 2011 by Don Ardonio

Software, as any complex product, will have defects. Plain and simple, no point in denying the facts. That said, the question is how can we handle them. First and foremost we should obviously strive to have as few as possible but the question I want to talk about here is what do we do with those that we didn’t avoid.

Classifying bugs

Let’s take a step back first and see what really is a defect. From an end user point of view, anything that is present but doesn’t work as the user wants/expects is a problem. Some of those will be cleared by explanation, others by declaring it a change or new feature and some will be proper problems with how the code behaves. The second and third option there share a rather large grey area and at times flipping a coin is as good a tool as any to decide, so I won’t go into that either. Suffice to say that after some deliberation you’ll end up with problems that you deem related to unintended behaviour of the code itself. It’s those that I want to further classify in 3 subdivisions:

1. Legacy bugs
Legacy bugs are the result of legacy code. Legacy code is all code that has been around long enough to not be considered new anymore (either developed in the project or inherited from previous projects). Generally I stick a 1 year age limit on that. If functionality has been in the software for a year I find that it is not relevant anymore in terms of gathering statistics. This irrelevance is generally down to team changes and the fact I would hardly ever go back beyond 12 months for metrics calculation like velocity.
2. New bugs
As the name suggests, these are bugs that have been found recently, in code that is not legacy. A bug will remain in this ‘new’ state for some amount of time. I find that 2 to 3 iterations is a good working average (in 2 week iterations) but that is very context sensitive.
3. Deferred bugs
These are new bugs that have “expired”. So it’s essentially a new bug that didn’t get fixed while it was still considered new.

During a sprint

In this model a sprint’s content is conceptually divided in 2 pieces. A first part is items from the backlog. These could be stories, research tasks, legacy or deferred bugs. Basically anything that has an estimated amount of storypoints on it and that the product owner put as a high enough priority so it fits within the available capacity for the sprint. The other part is a % of slack that is built into the system to absorb new bugs (and depending on your situation perhaps even critical support calls). I find that a good way to manage slack is by applying some elements of KanBan to it.
As bugs come in they enter an input queue, where the product owner can give them a priority (by ordering or classes of service or combination of that). Generally a first step is analyzing the bug after which the PO can decide to either defer the bug or keep it in the flow for “immediate” fixing.
The other element in this story is that bugs that are in the input lane for longer than a set time (2 to 3 sprints sounds good, depending on your sprint length) the bug is automatically deferred. The logic being that if it was important enough it would have been fixed in that time and you don’t want your system being dragged down by low value work. As you want bugs to get fixed rather than being in limbo I advise to keep WIP limits extremely low in this system.
So summing it up, you could say that the team actually pulls work from 2 systems. On the one hand there is the scrum process which runs as usual but within a designated section of the sprint there is actually a KanBan system working behind the scenes.

Getting on with planning

From a planning point of view the Scrum rules remain. All work on the backlog needs to be estimated and prioritized. So legacy and deferred bugs are estimated just the same as other items on the backlog. They are just another input, no different from customer requirements in the way they are handled. During sprint planning they are scheduled as normal part of the sprint. So don’t go scheduling them in the slack as that is specifically designed to handle new bugs.
Estimating bugs is generally not easy, so allowing the team to analyze enough to be able to estimate is a good idea. For legacy bugs and bugs that were deferred because they weren’t picked up this falls under the normal backlog grooming activities, bugs that were explicitly deferred after analyzing shouldn’t need much more research. The idea is to get just enough info so the bug can be estimated, not to go off and fix it right then and there.
Another point is that bugs vary much more in size and complexity than a typical story, so particularly for those very small bugs it can be good to just bunch up a few and call it 1 storypoint rather than trying to estimate each one. This will keep your velocity a lot more representative for the work that is actually done.
The amount of slack that you build in is a trade off that only the PO can decide on, on a per sprint basis, as it clearly represents an amount work that the team has to do. It will always come down to a choice between making forward progress (i.e. doing ‘new’ stuff from the backlog) and keeping the amount of technical debt in check. Should the PO decide to not have any slack at all it stands to reason that all bugs will automatically be deferred.

Another word on the classification

There is one last element missing in the above classification, which is bug recurrence. Understanding what kinds of bugs you get and which ones return (or in which areas of the code if you take it a bit broader) is very helpful in driving quality focus but also in planning.
A simplified example: Suppose you measure that about 5% of bugs return after each round of QA and/or user acceptance. That means if you have a log of 100 bugs you need 2 passes. There will be 5 left after the first pass and 0.25 after the second, meaning the product can be deployed. On the other hand if your rate would be 30% you’re looking at 4 rounds of that. Understanding this pattern is a big help in avoiding those bug squashing weekends right before a release.

The last word is for the user of your software

From the user’s point of view it doesn’t really matter what type of bug you have or how you prioritized it, all that matters is that their problem is solved. That is a very important thing to keep in mind as that is the primary measure for defect handling imho. How many defects are you getting, how many are recurring, and particularly how fast do you get the solution deployed to your users. People who forget to measure that last one (actual deployment, no earlier semi state) are missing the main aspects of handling defects.

Share and Enjoy:

Posted in agile, communication, development, kanban, management, product owner, scrum, software | Leave a comment

The Prince-iples of Agile

Posted on November 19, 2011 by Don Ardonio

Lately I’ve been thinking a lot about traditional project management methods. In part to understand why/where they fell short for software and what their use might be. Some elements in the agile community seem to feel very strongly that all classic methods are evil and agile is the one true way. What I tried below is to go back to the principles behind a classic method, in this case Prince2, and see how that is different from Agile principles. Below I’ll be drawing primarily on Scrum as the example for Agile methods, even though I will refer to Agile in general on occasion. For those of you unfamiliar with Prince2 having a read through the wiki entry might be good because some of the terms might have a slightly different twist to what you’re used to in corporate. Similarly for those not familiar with Scrum a quick read on wiki should help you through.

1. Continued Business Justification

A Prince2 project must at any time have continued business justification. This is done by actively maintaining and regularly reviewing (and explicitly approving) the business case.
At the end of each iteration a potentially releasable and done increment is produced. Which means that after each iteration the project could be halted.
The difference: Agile does not have the explicit business case but puts a hard focus on making sure that the project leaves value behind, even if killed early on. Prince2 on the other hand is typically reviewing the business case at the end of a stage which tends to run a lot longer than an iteration in Agile.

2. Learn From Experience

Prince 2 has this as a very explicit element in the methodology that runs somewhat throughout all activities
One of the core principles of Agile methodologies is “inspect and adapt”, this goes for artifacts like the backlog just as much as it goes for the how the team works.
The difference: Prince2 simply states that throughout the project (i.e. in all reports and reviews) and during start-up and closing stage lessons should be sought, recorded and acted upon. Agile/Scrum is a lot more explicit in doing this by nature of having to continually refine the requirements. One of the big differentiators for me is that Agile also invites to challenge the methodology implementation itself during a retrospective at the end of each iteration, which is fairly unheard of in Prince2 as far as I know.

3. Roles and Responsibilities

Prince2 defines explicitly the roles and responsibilities through the executive sponsor, senior user(s) and supplier(s), a project manager at a minimum.
Scrum defines Product Owner, Scrum Master and Development team, with very clear responsibilities
The difference: Prince2 puts a lot of focus on the management side of things and how those parties interact with little focus for the hands actually doing the work. Scrum takes a more inward looking approach and defines the interactions so that the work done can be optimized but by and large ignores everything that is outside the team (that all falls under the “the product owner represents the business” line…)

4. Manage by stages

Prince2 defines stages to ensure that senior management has control points at major intervals throughout the project. At the end of a stage the project status is reviewed (including the business case, see above) to assess viability of the project
The concept of breaking the work in blocks is inherent in the iterative nature on Agile and leaves us with a natural control point. Where Prince2 really goes to senior management Scrum tends to stop at the Product Owner who is empowered to take these kind of decisions.
The difference is mostly in the length and intention of those blocks. Prince2 has those blocks as major points in time (typically these would be releases implemented over several sprints in Scrum) to provide a big set of functionality and provide a point of evaluation for the project at large. Besides providing a point for evaluation and reflection, the idea behind an iteration is equally to be able to quickly react to changes and discover obstacles quickly.

5. Manage by exception

Prince2 has defined tolerances for each project objective to establish ground rules and limits of delegated authority.
Agile defines decision authority at the lowest reasonable level (e.g. the team is said to be self organizing so it has full authority to decide how a feature will be implemented, the PO decides what features will be implemented in what priority, … ).
The difference: Prince2 assumes that end responsibility is at the top of the organization and is delegated downstream (within well defined constraints). When exceptions occur the level that granted the authority is alerted. Agile does not take this top down model but defines authority at the place where the work is done. When something prevents that work to be done (i.e. the team needs more info from the PO) there is a trigger to look for help outside but since there is no explicit delegation of authority there is no “up” level to inform.

6. Focus on Products

A Prince2 project focuses on the definition and delivery of products, in particular on their quality requirements.
Obviously in Scrum there is the fact that the end of each iteration should produce a releasable and done product. The word “done” in that sentence is of utmost importance. It is that definition of done that ensures (amongst others) that quality is not dropped, documentation is present, … .
The difference: Prince2 is very clear on defining the product up front at adequate detail. However the purpose of this product definition is to define the product’s purpose, composition, derivation, format and quality criteria and quality method. Satisfying that does not necessarily mean waterfall, however it is often interpreted like that. Agile does aim to define all those things too, however the point at which they are defined is different. Agile will define this at the latest possible moment (i.e. right before the iteration starts) and will plan the iteration accordingly.

7, Tailor to suit the environment

Prince2 should be tailored to suit the project size, environment, complexity, importance, capability and risks. When tailoring it is important to remember that Prince2 requires information (not necessarily documents) and decisions (not necessarily meetings)
Scrum does not leave much room for tailoring but is rather strict on a very limited set of elements. Tailoring Scrum isn’t so much removing things from the methodology but rather extending it with good/best practices.
The difference: Prince2 was set out to be a very generalist method which means that a lot of things in the framework might be less relevant for your particular situation. Scrum aims to be very good at managing software development projects which means the methodology could be reduced to only contain things relevant for the projects it aims to be good

The last paragraph
The reality is that project management methodologies, classical or otherwise are not that different in what they try to achieve. Ultimately all aim to deliver projects within the business constraints in such a way that said projects can be done in an orderly fashion.
The biggest difference I think, and the reason why some classics got a bad rep, is because they have often been abused to enforce behavior that was counter intuitive for the type of project that is software development (i.e. a very R&D like activity which is hard to plan and predict compared to for instance building a house). Ultimately the classical methods are rooted in practices and experience learned before software was something that needed to be managed. When that became the case it was logical to draw on what was available and the methodologies grew and tried to (over)stretch and were somewhat blindly applied to software.
That is also the reason for one of my fears for the future of Agile. The very nature of Scrum (and Agile) was to do software in a very good way, when people will start to dogmatically take this approach and/or transport it to other types of work I’m afraid Agile might be the evil empire of the next decade.

Share and Enjoy:

Posted in agile, business, development, management, Prince2, scrum | 4 Comments

Winning is a habit

Posted on November 14, 2011 by Don Ardonio

Caught a few pieces of this on ESPN. I couldn’t have agreed more. This is speech is one of the most motivating things I’ve heard in a long while.

Watch the clip:

And here’s the full speech

Winning is not a sometime thing; it’s an all the time thing. You don’t win once in a while; you don’t do things right once in a while; you do them right all the time. Winning is a habit. Unfortunately, so is losing.

There is no room for second place. There is only one place in my game, and that’s first place. I have finished second twice in my time at Green Bay, and I don’t ever want to finish second again. There is a second place bowl game, but it is a game for losers played by losers. It is and always has been an American zeal to be first in anything we do, and to win, and to win, and to win.

Every time a football player goes to play his trade he’s got to play from the ground up — from the soles of his feet right up to his head. Every inch of him has to play. Some guys play with their heads. That’s O.K. You’ve got to be smart to be number one in any business. But more importantly, you’ve got to play with your heart, with every fiber of your body. If you’re lucky enough to find a guy with a lot of head and a lot of heart, he’s never going to come off the field second.

Running a football team is no different than running any other kind of organization — an army, a political party or a business. The principles are the same. The object is to win — to beat the other guy. Maybe that sounds hard or cruel. I don’t think it is.

It is a reality of life that men are competitive and the most competitive games draw the most competitive men. That’s why they are there — to compete. To know the rules and objectives when they get in the game. The object is to win fairly, squarely, by the rules — but to win.

And in truth, I’ve never known a man worth his salt who in the long run, deep down in his heart, didn’t appreciate the grind, the discipline. There is something in good men that really yearns for discipline and the harsh reality of head to head combat.

I don’t say these things because I believe in the “brute” nature of man or that men must be brutalized to be combative. I believe in God, and I believe in human decency. But I firmly believe that any man’s finest hour, the greatest fulfillment of all that he holds dear, is that moment when he has worked his heart out in a good cause and lies exhausted on the field of battle — victorious.

- V. Lombardi

Share and Enjoy:

Posted in leadership, motivation | Leave a comment

Retroflection – Why are you reporting to the Scrum Master in your stand-up?

Posted on October 20, 2011 by Don Ardonio

Retroflection is a project started nearly 2 years ago by Yves Hanoulle. The idea is to (frequently) tweet something to think about, related to agile software development.

Today’s tweet: “question 658 Why are you reporting to the Scrum Master in your stand-up?”

I was a bit surprised when I read the question. Particularly the way it is phrased leaves me with an image of one of the most common misunderstandings in agile and in particular with the daily stand-up. There are 2 elements in that question that I’ll address. First of all the reporting aspect and secondly the direction of that.

Bold statement number one: stand-ups are not for reporting

I’ve been in one too many stand-ups where people come in, ramble off their prepared answer to the 3 questions (what have you done yesterday? What will you do today? What’s blocking you?) and shoot back to their desks straight after. Those 3 questions have a purpose and it’s often missed. The first question is aimed at uncovering problems early on in the process. If you ran into a problem, are getting way off track, got interrupted all the time, … those are the things that the question is trying to uncover. If all went okay and you are making good progress and finishing what you aimed at, the answer should really just be “On story Z, did what I set out to do, all went well”. It’s by no means the time, nor the place, to give a detailed recap of your day.
The question about what you’ll do today is where I expect a bit of a breakdown of what problems you’ll tackle and some pretty good idea of what you’ll finish or how far you hope to get along in that solution. This is also the point where you can throw out some ideas on your approach. Again, don’t get into the nitty gritty details of that but a line of thinking or simply saying you’d like someone to sit with you and talk through it are great points for this question. It’s also the place where other people can maybe point you in a direction or in general make sure that they are not creating too many problems (for instance by being in the process of changing the interface you’re coding against).
The final question is a direct hit at stuff that is blocking you. That could be anything ranging from IT problems or the sales guy next door being too loud to being stuck on a particularly hard piece of code or some area of the project that’s new to you. The point here is that it will most often be direct actions for the scrum master to make sure these problems go away (how the scrum master does that is besides the point here…for now just assume it involves magic powers).
Last thing to point out, teams frequently let stand-ups get to 20 or more minutes and it becomes a bit of drag. If you answer the questions towards the nature of why they’re there I found that stand-ups often only take a few minutes and hardly ever run beyond 10 minutes (even on 10+ teams).

Bold statement number two: you report to no individual and definitely not to the scrum master

As I tried to point out above, the stand-up isn’t about reporting but rather about making sure that problems are uncovered quickly and that you also get the benefit of full knowledge in the team. That is essentially why you are not giving a status report. Many people I talk to have the impression that a stand-up is a new management trick to monitor their daily activity. It’ s not All you do is share in the team where you are. Remember that it is the team who commits to the stuff in a sprint, so equally so it’s important that as a team you reach that goal. Because of that commitment, it’s important that everyone in the team understands the progress (yes, burndowns show this too). So you are not reporting to an individual, you are just being part of a team that set out to achieve the goals of a sprint.
Special mention for the scrum master…the scrum master role is there to ensure that the process is followed. He is a mediator in the stand-up. He’ll make sure you don’t get into an hour long technical discussion between 2 members, takes impediments out of the meeting, keeps an eye on the scrum board,…. So there really is no point in telling specifically to him what you did since he has no vested interest in achieving the sprint goals, only in making sure the team can achieve those in the best possible conditions.

Share and Enjoy:

Posted in agile, scrum, software, twitter | 2 Comments

Lean Kanban 2011 impressions

Posted on October 7, 2011 by Don Ardonio

I attended the Lean Kanban 2011 conference earlier this week and aside from the great sessions, a couple of things really struck me. So rather than giving a content replica of sessions I attended, this is all about observations and impressions.

Number one: Know your problem
This is probably the thing I noticed most of all: The “agile/lean movement” has become very aware of its purpose. I’m sure that guys like David Anderson and Al Shalloway always have been aware of this, but this is the first time I heard people warn about my biggest fear: agile methods becoming dogmatic rather than solutions to a problem. For me, this is really the key to any method. I guess in saying that, I also started to believe that the water between the likes of John Seddon and others isn’t all that deep. It all starts by studying demand! I need to make a sidenote here that netobjectives is providing lean-agile project management certification courses. As with all certifications, I understand the need but I also realize this is often the first step to training people who are certified in the procedures and methods and not in the mindset. As Dave Snowden put it so nicely: We need more chefs, not recipes.
For me this is where the biggest challenge will be in the future. No matter what your method of choice is, it should be suited (and tailored) to answering your problem and not trying to fit your problem to the method.

Number two: Diversity
Where last year, apart from the speakers, most people were on roughly the same level of adoption (at least that was my impression), this year boosted a huge range on the adoption scale, both in the speakers and in the audience. To give an example at the end of one of the sessions someone in the audience asked to explain lead time and in a different session I heard interesting conceptual discussions after a presentation.
To me this diversity signifies two things. First of all that the adoption rate is rising (which comes with a certain set of benefits and drawbacks) and secondly that there will be a lot of consulting opportunities (which is nice since I’m in that business…)

Number three: Keynotes
Let there be no misunderstanding. The keynotes were of very, very high quality. The content and the way it was delivered was outstanding and was what a good keynote needed to be: thought provoking content brought in a rather light way.
I am sure that some people will not have liked the “bashing” between some of the keynote speakers but I personally don’t mind that. The thing I take away from the keynotes is not a right/wrong story but a story that forces you to reflect.
Personally this reflection included some of the following for me:

The need for more chefs and less recipes
In short this is the essence of my first paragraph. We need to have people who can understand and adapt to the situation, with understanding of the methods available. Not just method implementers.
Purpose, measures, methods
This wasn’t my first John Seddon speech so I already knew this one, but it’s just something I reflect on regularly. People will generally find methods that work towards the measures, so it makes sense deriving measures from (customer) purpose, in customer terms. I think that in today’s world we fail too often in finding the right measures and therefore inherently flaw our methods (and defeat our own purpose)
We’re dealing with people
I realize that is an obvious statement but it makes me reflect on several elements of that. In part, this goes back to the work environment. How much fun are you having at work? It also makes me think about the simple fact that everybody can have a bad day, including me. It also ties in with the availability system from Seddon’s talk, the system needs to take care of providing the right ability to deal with the customer’s problem but should at the same time be designed to provide training opportunities.

Share and Enjoy:

Posted in agile, event/conference, kanban, scrum, software | Leave a comment

On motivation of teams

Posted on May 17, 2011 by Don Ardonio

One of the things I enjoy most in my professional life is the challenge that comes with building and guiding a team. In this post I’d like to offer an opinion on 3 factors that have a tremendous effect on motivation of teams: The team composition, the diversity of activities and the environment.

Starting with possibly the most obvious of those: The team’s composition. When at liberty to build a team I tend to look most of all for uniform variety. That may sound a little contradictory at first but let me explain.
First of all, on the individual level I look for people with a passion for what they do (which in my case is typically software development). No matter what team or individual, there has to be a shared layer of passion about what you’ll do for at least 8hrs every day. In case you are not passionate about that, don’t bother applying.
My second highest thing to look for is character and team spirit. It’s part of how you would do in a team, but it also relates to having an opinion and how you react to various situations.
So, having figured that out as much as possible during the interviews, I try to compose a team that has a lot of variety. However the variety is chosen so that in the end each side is covered by an equal counterpart. I’ll have introvert people countered by very outgoing individuals, experience by raw potential , … . Particularly that last bit to me is very important. It’s having more senior (not necessarily in age) people on board for a number of reasons. First for the obvious maturity and experience they bring to any team but secondly also to help guide the junior members. I try to achieve rotation where the raw potential gets experience and learns so they can train incoming potential and keep the team eco system running.

After the composition of the team the next big important factor is the diversity of what they do. Goes without saying they will be focussed on a specific topic and/or technology and most likely work on the same project for some time, but even within a project there generally are ways to keep people challenged and refreshed. I am not claiming people should switch tasks every few days, but during the course of a project they should definitely have taken up different roles (i.e. caring for the build, lead on a specific topic,…).

The last factor in my list up top is the environment the team is in. Obviously the environment a team is in is partly defined by their peers, hence why I spent quite a bit of time earlier on that. The other part though is one where the company has much more influence than it actually thinks. It is the space in which the team operates and how the infrastructure supports them. This discussion goes beyond the private office/landscape setup (I believe in an open space with corners where people can dive in for meetings or to get some quiet time…). It is how your company is set up to support the team. For instance, the mere fact that a developer has a standard issued corporate laptop can be a problem. Part of running a good/healthy/fun business to me means supporting what is most important to you, and believe it or not, but in 99% of the cases that will be the people doing the work. Obviously there is a business reality you live in and there is a need for structure and procedures to run it efficiently…but that should never stop you from trying to tilt the balance in favor of a good/fun/healthy atmosphere for your team.

Share and Enjoy:

Posted in business, leadership, management, motivation, strategy | Leave a comment

Starban

Posted on April 25, 2011 by Don Ardonio

I have always been fascinated by Starbucks and how they operate their stores. On a macro level they are very similar to McDonalds, Dunkin’ Donuts and others of that breed, in the sense that their main focus is real estate. The differentiating factor for them is not the better bagel, salad, donut, milkshake or anything they sell (branding is important though, but that’s a different discussion entirely). A large part is a matter of finding the better real estate. Finding that corner where more people are likely to enter. On a micro level, their stores all run according to the same proven plan.

Think about your favorite Starbucks for a second and look how they have set up their operations. You come in and enter a queue where you are picked up by someone asking what you want. As a result of that there is a cup with your name on, sitting idle until the barista has a spot open on his coffee machine. At which point your hot, steaming, divine beverage is brewed and finally put at the end of the line on a tray, ready for you to be picked up and enjoyed.
Isn’t that the most wonderful example of a pull system with limited WIP?

Let’s have a look at you, the customer with a vague requirement. The only thing they really know about you at first is that you probably want some kind of drink, and even that is not entirely guaranteed. Walking in puts you in a fifo queue where your requirement is analyzed when the first person behind the counter is available. You are not shouting your order randomly expecting it to get done, instead someone is asking you what you want. They are pulling you into the system.
Once your request has been broken down into subtasks several things start happening. Let’s stick with you for another second.
First of all, you pay for your order. This is a vital step as it represents approval to go through with the requested work once it’s been analyzed. After that you start receiving incremental releases, each adding more value to completing your request…Your cookie arrives before your coffee. Until, in the end all the work for you is done and you leave the system (either out the door or keep hanging out in the store because it’s too cold outside)

That was you, in a nutshell. Let’s take a look at your coffee now…

Your order has been broken down into pieces, it’s been approved and now there’s a empty cup with your order on it. It just sits there, waiting for a slot on the coffee machine to open up. If that spot does open up, the barista pulls the cups from a fifo queue and processes each order until it’s put as a finished product on a tray. Generally this point completes the order. A pretty obvious case of a pull system with wip limits I’d say. Actually, the entire order processing system is a prime example of a pull system with wip limits and a strategically inserted queue right before the brewing. It’s also clear that the process for larger requirements (i.e. your order) is not the same as for the individual steps (your coffee). Epics don’t necessarily follow the same flow as lower level tasks.

There are 2 other interesting questions in this for me. First of all, why is that queue there in the middle? And secondly, what happens when the system reaches its limits?

Turns out the answer to both is related.

Let’s start with the latter question. What happens when the system gets overloaded is pretty obvious. People focus on removing the overload. In case of Starbucks this can mean a variety of things, but ultimately they are always bound by the mechanical constraints. Either that is the processing time of the coffee machine or the cash register or some other mechanical part. Apart from shifting some resources to deal with moving cups around faster, there isn’t much they can do beyond actually scaling the infrastructure.

Back to the first question then, why is that queue there. Imagine rush hour at your local Starbucks. There’s a line of people waiting to get coffee and the machines are all running at full capacity. In its purest form, the system would dictate that a delivery at the end would mean an open spot on the coffee machine, which in turn would mean a new cup could be pulled in, hence a new customer could be giving his/her order. Or put otherwise, the lead time for a customer would be the shortest possible. What this means however from a customer standpoint is that you spend a portion of your time waiting to get into the system, or put slightly more blunt…your requirement is ignored. To tackle this, a queue was inserted right before the brewing. Which effectively means that you, the customer, get to enter the system sooner and have a feeling you are better cared for (it’s moving along after all, you already placed your order and payed for it).

So, ultimately, Starbucks has decided to sacrifice some lead time in order to give customers a better overall experience. How about that!

(lovingly dedicated to my grande americano with extra shot, and a chocolate chip cookie…)

Share and Enjoy:

Posted in agile, kanban, personal, software | 2 Comments

The hotmail CV tax

Posted on April 21, 2011 by Don Ardonio

Whenever I have a (technical) person applying and they have a hotmail address as their preferred means of contact I shiver ever so slightly. Even if the actual mailbox is very sensible like name.firstname, I still shiver. The problem is that I will automatically be biased for whatever else you have to say.

Don’t get me wrong. I have no problem with hotmail as such. It’s a mail box, you can send and receive email, access them online, use the windows live ID (and, by extension, myspace), … . So really, there isn’t much wrong with it in terms of very basic email service.

However, as a techie I expect you to expect more than just those basics. I somehow assume that you understand the need for, at least, powerful search in your mailbox. Next to features, there’s also the up-to-date factor of a hotmail address. Let’s face it, hotmail has been around virtually as long as the internet and at some point we all have had at least one account there. Using that, presumably, old address does not tell me that you try to keep up with what’s new. Right now, the consensus seems to be that gmail is the way to go. Either that, or your own domain. Be aware though, if you have your own domain I will go check it out so please make sure that the content on there is something you are not afraid of sharing.

That’s as far as today’s standards go. Hotmail (or planetinternet, AOL, … ) is a total no go. It has clueless wimp written all over it. Yahoo is less bad but it doesn’t really fill me with confidence that you still use it. Gmail is totally okay and you get bonus points if it’s something like firstname.lastname.jobhunting because it tells me you’re organized (I would expect you to consolidate everything in a single firstname.lastname account behind the scenes though). Using your own domain is great but be careful of the content of that domain.

In the near future I think Gmail will still rule for several years to come. I do however expect that, when the job market gets flooded with internet natives, things like facebook and/or linkedin addresses (assuming they will create something like that) might start popping up on a CV. And that will change the game of how we communicate and recruit today. A challenge for sure!

Share and Enjoy:

Posted in business, communication | 1 Comment

ardonio.com

Retrospectives

Velocity

Defect handling in an Agile approach

The Prince-iples of Agile

Winning is a habit

Retroflection – Why are you reporting to the Scrum Master in your stand-up?

Lean Kanban 2011 impressions

On motivation of teams

Starban

The hotmail CV tax

Recent Comments

Meta