Example 3: Using a Project Manager with Iterations and Kanban and Silo’d Teams

Here, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. The Indian testers were very smart, and unfamiliar with the product, so the developers suggested the testers test feature by feature inside the iteration.

The project manager suggested they use cumulative flow diagrams and cycle time measurements to make sure the developers were not developing “too fast” for the testers. The developers, still smarting over the loss of “their testers” were at first, peeved about this. They then realized the truth of this statement, and developed this kanban board.

You can see in this board, that four items are waiting to go into system test. Uh oh. The developers are out-producing what the testers can take. This is precisely what a kanban board can show you.

The testers aren’t stupid or slow. They are new. They cannot keep up with the developers. It’s a fact of life, not a mystery of life. The developers have to act in some way to help the testers or the entire project will fail. The reason they are working in timeboxes as well as using kanban is that they have several contractual deliverables, that management, bless their tiny little hearts, committed to. The timebox allows the team or the product owners to meet with their customers and show them their progress. (They were deciding who would meet when I last worked with the team.) The kanban board help make the progress even more transparent.

Iteration planning: The product owner and the project manager jointly work on the agile feature roadmap, and the product owner owns the roadmap responsibility for it. The product owner owns and generates the backlog. The product owner and the agile project manager present a strawman iteration backlog to the team at the start of the iteration. They have had difficulty finding iteration planning time that allows everyone to be awake and functioning, bless the senior managers’ little hearts.

Daily commitment: They do a handoff, asking each other what they completed that day and what the impediments are. If you have read Manage It!, you know I modified the three questions to “What did you complete, what are you planning to complete, what is in your way?”

Measurements: cumulative flow, average time to release a feature into the product. They are experimenting with burnup charts and impediment charts. They are still having trouble bringing the testers up to speed fast enough.

Yes, they do retrospectives at the end of each iteration. Yes, the product owners own the backlogs.

I’ll summarize in the final part, the next entry.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

                                                                                                                            By Dominica DeGrandis Everyone (myself included) seems to be having a crazy busy week. 2012 appears to be evolving rapidly.  Let’s remember to find the solitude necessary for creativity and balance.  Speaking of balance… News Balancing near term and long term efforts can sometimes turn into heated debates when prioritizing tasks.  In this post, Jabe Bloom discusses “big scary company killing problems that are obvious to some, but unseen by others”. http://www.calmbetawave.com/2012/01/death-rests-within.html “The Science of Kanban – People” by Karl Scotland dives into the neuroscience behind visualization, multi-tasking and learning.  I enjoyed his clean simple explanation on double-loop-learning. http://availagility.co.uk/2012/01/30/the-science-of-kanban-introduction/ Seattle Lean Coffee was a hit this week with 15 people in attendance.  The favorite topics converged on handling “Command and Control” leaders and consultants “Inflicting help“.  I’m hoping we’ll see a recap of the session soon. http://seattle.leancoffee.org/ Pawel Brodzinski continues his journey with “Project Portfolio” with details on how and why he evolved his kanban board and cards. He reveals the need to bring visibility to projects at risk vs. projects doing well. http://blog.brodzinski.com/2012/01/project-portfolio-kanban-first-changes.html A Bill Fox interview with David Anderson relays that Kanban is not a method.  Instead, it is a way to propel an organization toward change - change which is contextual and unique for each organization. http://www.foxhighperspective.com/blog/?page_id=367 Events The Inaugural Cynefin, Agile & Lean Mashup (CALM) – London, UK Feb 16 -17, 2012 http://calm.eventbrite.com/ Agile and Beyond Conference - Dearborn, MI.  March 10, 2012 http://agileandbeyond.org/ Lean Kanban Southern Europe - Madrid, May 9-10, 2012 http://lkse12.leanssc.org/ Lean Software Systems Conference – Boston, May 13-18, 2012 http://lssc12.leanssc.org/ Resources Lean Kanban University (LKU) http://www.leankanbanuniversity.com/ Kanbanops http://tech.groups.yahoo.com/group/kanbanops/ Kanbandev http://finance.groups.yahoo.com/group/kanbandev/ Limited WIP Society http://www.limitedwipsociety.org/ #mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block.   We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ Subscribe to Weekly Kanban Roundup Please contact dominica@djaa.com with questions.

Voici les défauts connus sur la R4#3 :

1. La migration avec PostgreSQL ne fonctionne pas. Ce défaut est corrigé dans la version R4#3.1
2. Dans l’assistant, le changement de rôle de celui qui crée le projet provoque une erreur. Ce défaut est corrigé dans la version R4#3.1
3. Quand iceScrum est installé dans Tomcat et qu’on arrête le serveur, il arrive que le process Java continue à s’exécuter, ce qui ne permet pas de réinstaller une nouvelle version d’iceScrum. Il faut d’abord arrêter le process (avec Linux et Mac, on lance la commande ps -ax pour récupérer le numéro du process puis un kill -1 avec ce numéro), enlever le répertoire icescrum de Webapps, mettre le nouveau war et relancer Tomcat.
4. Quand on modifie la couleur d’une feature, ce n’est pas immédiatement rafraichi au niveau des stories.
5. Le fonctionnement sur tablette et smartphone n’est pas optimisé.
6. Si le serveur est configuré avec un proxy, il peut arriver que l’attachement de fichiers ne fonctionne pas quand le nom du fichier contient des caractères exotiques.
7. L’attribut pour donner la valeur d’une feature propose des entiers dans le formulaire, mais dans la vue table, c’est restreint à la suite de Fibonacci (au lieu des entiers). Ce défaut est corrigé dans le build 220.
8. Erreur quand un membre de l’équipe dont le rôle est développeur quitte le projet (l’équipe).
9. Le drag and drop pour ordonner les stories dans le backlog ou les features ne fonctionne pas quand on agrandit la fenêtre. Ce défaut est corrigé dans le build 222.
10. Une story estimée à 0 passe à ? en vue table ou quand on active le sprint. Ce défaut est corrigé dans le build 233.
11. Selon la résolution utilisée, le dernier sprint du plan de release s’affiche sous le 1er et pas à côté du précédent (avec certaines versions de Firefox).
12. La copie des tâches récurrentes du sprint précédent ne fonctionne pas. Ce défaut est corrigé dans le build 227.
13. Le lien vers le fil RSS ne fonctionne pas. Ce défaut est corrigé dans le build 229.
14. Dans le bac à sable, lorsqu’on ajoute plusieurs stories à la suite en utilisant le bouton « Proposer et poursuivre » et qu’on utilise le template « en tant que … », seule la première story ajoutée conserve les informations saisies dans le template. Toutes les stories suivantes saisies perdent les informations du template. Ce défaut est corrigé dans le build 233.
15. Lorsque le backlog contient suffisamment de stories pour que les post-it remplissent la fenêtre il est impossible de sélectionner les post-it de la derniere ligne pour les déplacer. Ce défaut est corrigé dans le build 229.
16. Lien incorrect dans l’historique utilisateur d’un profil d’une personne.
17. On ne peut pas mettre à jour le reste à faire sur les tâches dans la vue table du plan de sprint.
18. Il est possible de passer une tâche à fini même quand le sprint n’est pas commencé en mettant son reste à faire à 0. Ce défaut est corrigé dans le build 233.
19. L’association d’une story à une feature est perdue lors de l’importation d’un projet exporté.
20. Lors du changement d’état d’une story, il arrive qu’on ait le message « Cannot create a session after the response has been committed ». Dans ce cas là, l’information n’est pas poussée vers les autres utilisateurs connectés, mais le changement d’état est effectué correctement.
21. Avec IE7 et IE8, l’affichage du plan de sprint ne fonctionne pas, à cause d’erreurs JavaScript. Ce défaut est corrigé dans le build 233.
22. Quand une tâche a un fichier attaché, le lien pour le lire en vue Modifer ne fonctionne pas. Solution de contournement : passer par le quicklook.

Si vous en trouvez d’autres sur cette version, merci de les ajouter dans le bac à sable iceScrum.

Some of you probably already get this… some of you might even disagree… but unless you are building software as a hobby… chances are, you building software for money. In other words, someone is paying you to write software for them.

Why would someone pay you money to show up and write software? They are paying you money to write software because they hope to sell that software and get even more money in return. It is an investment.

Ideally, we should want our investors to get a good return on that investment so they’ll keep investing. It’s our job as software professionals to help our sponsors get good, working software into the hands of paying customers as quickly as possible.  That’s how we make money.

The act of selling software funds our ability to build more software.

Conversely, our inability to sell software makes investors grumpy and a lot less likely to want to keep paying you to write software. Unless we sell software, we don’t have any money to pay people to build software.

To many, the thought that we are writing software for money cheapens our craft… it cheapens our art. We want to be pure. We want to build perfect products. We want to perfect our craft and be artisans.

Don’t get me wrong, I’m all for building great products. That said, at some point, we have to strike a balance between perfection and getting products to market, products that can sell and start generating revenue.

Why am I writing this post?

Over the past few years, I’ve worked with a bunch of folks that have seem to have lost this fundamental connection to the economics of software development. Some where along the way, software became and end unto itself.

…somewhere along the way it became more important to be great engineers.

…somewhere along the way it became more important to be great testers.

…somewhere along the way the design became more important than the delivery.

Some where along the way, it became more important to deliver everything at one time rather than to getting something into the hands of our customers as quickly as possible. I think that mindset is killing many of our companies.

If you were spending your own money to build software, you’d want to see a return on that investment as quickly as possible. As software professionals, we have to start thinking about the economics of software delivery and act accordingly.  How would be build software if our own money was at risk and failure wasn’t an option?

Related Posts:

• Is Quality an Absolute?
• The Problem with Precision
• Sharing Risk With The Team
• Lightweight Documentation… Not Lightweight Thinking
• Working Software or Customer Value

Yesterday, the LAS Coreteam organized its first Scrum Breakfast without me. To fill in the spot left by the thought for the day, Kai asked me a few questions over Skype and edited them into a short video. The main topic was Stoos, but we also talked about this years Lean Agile Scrum Conference and the Scrum Retrospectives. You can watch the video or read the (partial) transcript below.



Q: The last I heard from you, you were getting ready for the Stoos gathering. What was the Stoos Gathering?

A: In January, a diverse group of 21 thought leaders, executives, and coaches from around the world met on the Stoos. Our inspiration was the Snowbird Lodge gathering with produced the Agile Manifesto.

Our invitation went beyond Agile and Lean practitioners to include Business, Leadership and HR communities. This group identified much common ground on how management should be and a tremendous discrepancy between that and how most companies are actually run. For instance, we believe organizations can become learning networks of individuals that create value. We believe the role of leaders should include the stewardship of the living rather than the management of the machine.

We want to facilitate the tipping point - the sustainable transformation of management from the command and control philosophy of the 20th century into something compatible with the context of the 21st century. I believe that Scrum, Kanban and Radical Management are examples of ways to "do Stoos," and other approaches will surely arise.

Q. How can people in Switzerland get involved?

A. Many ways: First join the conversation on linked in and twitter. The group is called the Stoos Network and it has a Linked In group, and our twitter tag is #Stoos (with two o's). Second, create or join and build community in your region to develop and exchange information on doing Stoos -- much like the Scrum Breakfasts. John Styffe is organizing a group in Zurich and I have started a Leadership Breakfast in Washington (together with the American University Business School).

Q. Is that why you are in Washington?

A. The driver was that the building I live in is being renovated and we had to go somewhere for 6 months. I had both personal a professional reasons for choosing the DC area. Steve Denning, the visionary behind Radical Management lives nearby. I want to work with him to make Radical Management a widely accepted approach for doing Stoos across the organization. So I plan to work on three things:

1. Create a course with Steve Denning around Radical Management and doing Stoos
2. Work on the WIKISPEED project - both on actually building cars and on helping this crowd-sourced project become a viable company that continues to live its Stoosonian values.
3. Develop the Stoos Community in Washington, DC.

A reader asked why the lifecycle in Agile Lifecycles for Geographically Distributed Teams, Part 1 is not Scrum. It’s not Scrum for these reasons:

1. The project manager and product owner start the release planning and ask the team if the release planning is ok. The team does not generate the initial draft of release planning itself. In Scrum, the team is supposed to generate all of the planning itself.
2. The checkin is different from the Scrum standup and the objectives of the checkin are different. I did suggest to the teams that if you want to create a cross-functional team where the functions are separated, if you ask people how they are working together, you might help them work together. Sometimes those questions work, and sometimes they don’t. It depends on the team and whether the people want to work together.

I didn’t mention retrospectives or backlogs in my examples so far, because I took them for granted. Yes, both examples of these teams do perform retrospectives and have product backlogs. They also have agile feature roadmaps, which are on my list to blog about.

The real difference is the difference between a Scrum Master and an Agile Project Manager. A Scrum Master is not a project manager. A scrum master does not manage risk by him or herself. A project manager will take on the risk management responsibility without asking the team.

A Scrum Master has only allegiance to the team. A project manager has responsibility to the team and to the organization. That means that the project manager might feel torn when the organization pressures the project manager to do something stupid. (Although, I just downloaded the Scrum Guide, and the Scrum Master’s responsibilities have grown considerably since I took my CSM with Jeff way back in 2006.)

But agile provides transparency when the organization asks the agile project manager to do something stupid, so it’s easier to retain your integrity as a project manager.

Want to move a feature higher in the backlog? Change the feature roadmap with the product owner and then change the backlog with the product owner. I expect the agile project manager to collaborate on the feature roadmap and the backlog with the product owner.

Want to change the velocity of the team to please some crazed manager? Both the Scrum Master or the agile project manager protects the team in these ways:

• Explain that velocity is not a productivity metric
• Say No and explain why
• Play the Double Your Velocity schedule game
• Or choose some other way to remove this management obstacle.

Agile makes it easy to protect the team. The question is this: does the Scrum Master have other responsibilities in addition to protecting the team or is the Scrum Master full time? An agile project manager tends to be full time on a geographically distributed team. Even on a geographically distributed team, a Scrum Master is not seen as a full time position. Bless their tiny little hearts, managers don’t seem to understand that transitioning to agile, especially for silo’d distributed teams with different cultural norms is non-trivial. They will make room for a project manager, but a Scrum Master? Oh no. Makes me nuts.

Cut corners on quality? I don’t see how. The team doesn’t meet the acceptance criteria on the stories and doesn’t meet their criteria of done for an iteration, and can’t show a demo. How does that serve anyone?

Help a team go faster? This is the one place where a project manager may have an edge over a Scrum Master, and that’s only because of education. An agile project manager is a project manager. That means he or she is actively studying project management, which means he or she is studying lean also, looking into work in progress. (I realize many project managers do not actively study project management.) I have high expectations of an agile project manager, and that is to limit WIP, work in progress, to measure cumulative flow. But, Johanna, that’s a lean project manager. Yes, that’s correct. Why not use all of the tools available to us at all times? This is not to help a team actually go faster, but to provide feedback to the team about their WIP. If everyone takes a story at the start of the iteration and everyone always works on their own story, it’s likely the team is at the slowest possible velocity. It’s worth knowing that, or at least retrospecting about the data. A project manager will gather the data. A Scrum Master, especially one who was not a trained project manager, may not know to gather the data.

I have nothing against Scrum Masters. Some of my good friends are CSTs (Certified Scrum Trainers). However, they are not all project managers, and have not been project managers, and have not studied the field of project management. Some have been. And, the real issue is this: In a two or three day workshop, they cannot convey to a person who may or may not have been a practicing project manager all of their project knowledge.

Organizations do not always pick project managers to be Scrum Masters. And, with good reason. Some project managers are command-and-control project managers. I suspect back in my long-ago past, I was. I gave it up long ago because it didn’t work. Some people never gave up command-and-control project management. Those people are not good project managers for agile projects. They are terrible project managers for geographically distributed projects, where you must work through influence.

You can have self-managing teams that are geographically distributed. You can have self-directed teams that are geographically distributed. But, they don’t start that way. They evolve into self-directed and self-managing teams. They start as management-led teams.

And, especially when they are silo’d teams, they need the coordination of a project manager, someone who will manage the risk between the silos, and someone who has the organizational backing, and yes, someone who has the allegiance to the organization to say, “We need to do this project” to write the project charter.

In a geographically distributed team, the agile project manager writes the project charter either with the team, or as a strawman for the people to edit and approve. Shane and I recommend that the people get together to write it together. We like it if people get together in person. We know how rarely that happens. (Penny wise, pound foolish.) So we teach people how to write a project charter when they are divided in space.

Because until there is a project charter, there is no organizing principle for the silo’d teams. Those developers in France, testers in Belarus, product managers and project manager in San Francisco, they all need something to coalesce around. The charter, which includes the project vision provides that. The iterations provide the project heartbeat.

So, that’s why I don’t think Agile Lifecycles for Geographically Distributed Teams, Part 1 is Scrum. It’s close, but no cigar. I respect Ken and Jeff’s work too much to call it Scrum when it’s not.

Now that I’m mostly recovered from my cold, I can continue the series about lifecycles.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

The ideal agile team is made up of specializing generalists – but what does that really mean?  The goal isn’t to prevent functional silos of expertise, it is to allow people to cover for each other.

Great Conversation

Elena Yatzeck (@eyatzeck) posted a comment on an earlier article about agile maturity models.

In terms of refinement, I’m thinking a lot these days about “staffing the engineering team correctly.” I’m not sure I agree in practice that you can or should try to staff all teams with “specializing generalists,” or at least not as taken to an extreme. (If you’ll forgive the self-promotion, I talked more about this here: http://pagilista.blogspot.com/2012/01/no-blender-zone-cross-functional-doesnt.html.)

I’ll not only “forgive” the promotion, I’ll re-promote it.  Good stuff.

When re-reading the maturity-model article, this snippet popped out at me:

People over process is the right emphasis. If you can’t find people that are “good enough” you might as well go home. Doesn’t matter how agile you are if you don’t have the horsepower. You also need people who are excited to “do agile” – they like to communicate, they enjoy the project and team dynamics of an agile process. You’re also better off with specializing generalists – ideally, every member of the team can do any work that is needed. This is an efficiency play – you risk introducing bottlenecks when you have a specialist who is the “only one” who can do particular types of work – because you will not have a consistent mix of types of work from release to release.
Agile Maturity Model

Thirty months later, my experiences have increased my conviction that this is true – and have realized that the way I wrote the quote above fails to provide a key clarification.

Following that link to an (even earlier) article on specializing generalists, brings the following (emphasis added):

The idea of specializing generalists is easiest to grasp by first saying what it is not. It is not staffing a team with a database expert, a user interface coder, a SOA (service oriented architecture) guru and an architect. With four specialists, each development task has an obvious owner. Database changes and refactoring go to the database expert. Reworking the UI goes into the queue for the AJAX hotshot. The problem is that this approach is only efficient when each team member is equally loaded with work. Since an agile team is continuously reprioritizing their work based on repeated feedback cycles as part of each release, this doesn’t work. The team will never face a situation where the (for example) four most important things to do are one item for each specialist. You can very easily have a release where all of the most important tasks are focused on the user interface. So all of the non-interface-experts are either working on lower-priority tasks, or even worse – they are idle. And you delay the most important work until the specialist can get to it.

By staffing a team with people who have an area of expertise, but can do anything, you can maximize the value of each delivery cycle. In our example, where all of the tasks for a release are UI tasks, they can be interchangeably assigned to any of the developers. The UI expert may suggest an implementation approach, do code reviews, or provide guidance to all the other developers. But every developer (including the database guy) can sling code effectively to get the job done. Specializing generalists.

This is very effective for making the “development engine” a black-box. Feed it the highest priority stuff, and it all gets done. We can take that approach to the next level. Designers can implement, project managers can design test plans, and yes, product managers can specify design. Twitch. Back up a sentence and read it again.

Specifying design is not the job of the product manager. True. Very true. Emphatically true. But specifying design can be what a specializing generalist does, even when that person is also responsible for defining market needs.
Specializing Generalists 2008

Elena’s article identifies a common misconception – that “specializing generalist” is a fancy way of saying “a bunch of people who can all do everything:

It’s a seductively simple fallacy of division to interpret the concept of “cross functional” team to mean a “collection of cross-functional individuals.” New agilists are quick to apologize that “we still have functional silos here” as though it would be much better if everyone could do all the same things. Grab some equally skilled poly-functional people, have them all take turns doing all of the jobs as needed, and you’ll all laugh your way to on-time, high-quality, and valuable working software.

Not so fast!

The power of an effective agile team, like the power of any other effective team, doesn’t come from its homogeneity, but from its ability to harness its diversity.
No Blender Zone: Cross Functional Doesn’t Mean Homogenous

Elena goes on to say (emphasis mine)

Team members shouldn’t attempt to Harrison Bergeron themselves into a mish-mash of mediocre (but working!) software. Someone needs to facilitate the stakeholders into some sensible semblance of a business case. Someone needs to build functional test suites that mercilessly beat on the code to prevent it from breaking in production. Neither of these are exactly the same skills it takes to gradually evolve the design of a complex system in modules of 100 lines of code or less. If people want to try new things, that’s great, but it needs to be with the realization that other jobs on the team are actual professions with skills and the need for experience in order to excel.

I completely agree.

Specializing Generalist

Specializing Generalist.

• Not a specialist.
• Not a generalist.

You need best of breed team members who specialize in areas of experise – “actual professions with skills,” as Elena puts it.  Without people who excel in the needed areas, you end up with a mediocre product.  How many times have you gone to the store and asked for the “middle of the pack” product?

That’s not even table stakes anymore.  Just the ability to create “something” isn’t interesting in the market, and isn’t interesting to the members of the team.  How many times have you heard someone brag “I love my job, I’m a cog in the machine?”  You have to have people who specialize in all of the needed areas (interface design, market insight, coding, quality, etc) in order to create a viable product.

If you staff your team with (only) generalists you will fail.

Pure generalists cannot create a product that is “good enough” – because they aren’t good enough at the creating the parts, from which the product is the sum.  You have to have people who specialize in creating great “parts” of the solution.  That’s what you need to have a shot at creating a great product.  But it isn’t really enough.  The problem is in how you define “great.”  Great means that customers buy it, users love it, and your competition is knocked back on their heels by it. Everyone agrees on this, but most people miss one thing.

Your market is changing – you also have to be fast.  You can’t solve the right problems if you aren’t fast, because the problems that are “right” are constantly changing – your market is a moving target.

Specialists, as individuals, are capable of creating great “parts” in their silos, and those parts all add up to a “great” product, so what’s the problem?  The problem is that collectively, by the time the specialists are done, they are no longer solving the right problem.

If you staff your team with (pure) specialists you will fail.

The most important tasks for the team, in any given sprint, will not balance into a perfectly allocated workload, where each “part” is worked on by each specialist, where no one is idle, and no one is a bottleneck.  It just doesn’t happen.  I haven’t seen it in 15 years in the software world, or in my prior decade as a mechanical engineer.

When one specialist is waiting for something important, she isn’t idle, she’s just working on something that is by definition not as important.  OK, you’re minimizing the damage – but you’re still taking damage.  When another specialist is the bottleneck, you lose.  Nothing magical to do here.

If you staff your team with specializing generalists you may succeed.

The work that piles up in any one specialized silo is of varying degrees of complexity.  The “UI specialist” may be backed up with a bunch of CSS tweaks, some straightforward AJAX calls to write, and a gnarly refactoring of the model-view-controller model to adapt to changing understanding of market needs.  No one can solve the MVC problem without specialized skills – but with guidance from the UI expert, one of  the other team members can handle the AJAX calls and CSS updates.  Extend this same model across other aspects of the product.  Your database expert may be needed to optimize query performance or resolve locking problems, but other members of the team could make straightforward schema changes.

It is the collective ability of the team to optimize what they collectively work on that accelerates the team’s delivery of the most important capabilities.

You have to have people who specialize, in order to optimize individual performance.  But your team needs to be built with specializing generalists in order to optimize for team performance.

T-Shaped People

From an HR perspective, I was taught about “T-Shaped People” – people who have breadth and depth of skills.

• Specialists are “I-Shaped People” – people who have depth of expertise, without breadth
• Generalists are “Minus-Shaped People” – people who have a breadth of skills, but no depth of expertise.
• Specializing Generalists are “T-Shaped People” – people who have depth of expertise in one area, combined with a breadth of skills across many areas.

These are the people you’re going for.

Thanks Elena for re-invigorating the discussion!

In December 2011, cbsnews.com published an article by Dave Logan, Ph.D., author of Tribal Leadership, suggesting that “work-life balance “ is a crock, an idea whose time has come and gone. Although I too have felt that this is an unrealistic ideal, I’m not so sure that I could clearly articulate what I do believe about this idea. I decided to take a look at some other current commentators writing about work and life balance. Here’s a sample of what I found:

David Greuse at Convergence Design, noted that “…we reject the notion of work-life balance, although we take the idea very seriously. To us, the phrase ‘work-life balance’ suggests that ‘work’ and ‘personal life’ are two separate categories that must be kept in separate containers lest a toxic mixture result. We believe the opposite: that work and personal and community commitments should be merged into a seamless whole that might be called ‘life’. Work is not antithetical to life: it is an integral part of life.”1

John Beeson in a recent Harvard Business Review blog noted that for senior level execs there is no such thing as work-life balance. He says your work consumes all your waking (and most of your sleeping) hours. The best you can hope for is a power nap. Guess that leaves me out…

Edy Greenblatt says we should be asking a different question. Instead of wondering whether you have balance or not, we should look at all the facets of our lives and ask how we are performing. Are we fully engaged? Are we physically energized, emotionally connected, mentally focused, and connected to something significant in life? If the answer to any of these is no, one of our “muscles” likely needs to be developed.  The key is to identify what restores us and depletes us.  In both work and non-work activities, we must do more of what we find restorative.

Sherrie Bourg-Carter, author of a book on what she calls “High-Octane Women” says the bottom line is that balance needs to be self-defined; it’s what works for you and your family. If you allow it to be anything else, you’re only adding another thing to your “to-do” list.  And frankly, isn’t that list full enough?

Personally, the comment that resonated most with me was a few lines sent to me by a friend. I don’t think she wrote this but wise woman that she is, perhaps she did.  The comment was “Start with what’s scarce: time.  You only get so much, and you can’t hit ‘undo’.  Some things are abundant.  Time is not one of them.  The goal is to get so focused on what’s vital, that you get in the regular habit of saying ‘I don’t have time for that’  to anything that doesn’t serve what really matters.  Don’t fall into the trap of thinking there’s ‘work’ and ‘life’.  There’s only life.”

Here are just a few references if you want to read more on this topic:

Bourg-Carter, S. (2011). High Octane Women: How Superachievers Can Avoid Burnout (Prometheus Books, 2011).

Greenblatt, E. (2009). Restore Yourself: The Antidote for Professional Exhaustion. Los Angeles, CA. Execu-Care Press.

Footnotes
1 The Myth of Work-Life Balance: http://www.convergencedesignllc.com/blog/index.php/the-myth-of-work-life-balance/

A version of this blog was previously published at www.wcleadership.com.

Le plan de sprint constitue le cœur du suivi d’un sprint par l’équipe. Avec iceScrum les tâches, représentées par des post-it virtuels, sont positionnées dans 3 colonnes : à faire, en cours, fini.
Les possibilités de bouger les tâches varient selon les rôles. Parmi les rôles présentés dans un article précédent, c’est en particulier pour le ScrumMaster que les possibilités sont les plus étendues.

Pour en savoir plus sur ce que peut faire un ScrumMaster -et aussi les autres membres de l’équipe- lire l’article complet.

Nous avons vu les rôles iceScrum dans un précédent article : le ScrumMaster, le Product Owner et les Développeurs qui forment l’équipe Scrum, plus les StakeHolders.

Ceux-ci ne participent pas aux sprints comme les autres et dans iceScrum l’accès qu’ils ont sur les différentes vues est souvent en lecture seule. Cependant, c’est différent pour le bac à sable. Les StakeHolders peuvent notamment proposer des stories et les suivre.

Pour en savoir plus sur ce que peuvent faire les SH et les autres avec les stories, lire l’article complet.

 

Day One of Cooper's Interaction Design Practicum had many highlights. Some of the topics covered includes the following ideas, practices & tips: Design Is - Groundwork...

Bobtuse can be wildly informative

Priming for Cooper's Interaction Design Practicum, I visited Less and More - The Design Ethos of Dieter Rams at SFMOMA. Dieter Rams is a German industrial designer whose body of work is...

Bobtuse can be wildly informative

I’m very excited to let you know that we now have an online course on Agile Estimating and Planning. The course is a series of videos and interactive quizzes. Videos are a combination of screencast (slides) and live action of me. All videos are extremely professionally done–no handheld video camera or recordings of me talking into my iPhone.

The entire course is now available on the Mountain Goat Software site. Check out the free previews. The course can be purchased for streaming or for streaming + download. We also offer group discounts and an innovative, easy way for someone such as a manager, ScrumMaster or similar to buy and distribute licenses to team members.

The 44 videos are interspersed with 9 interactive quizzes. If you miss a quiz question, you get immediate feedback telling you what the right answer is. This approach may not hold up to some certification organization’s rigor, but it’s sure a helpful way to make sure you’ve learned the topic. You can see an example below.

The course qualifies for 4 PDUs from the Project Management Institute and is perfect for PMPs or aspiring PMI-ACP candidates. At the end of the course, you earn a Certificate of Completion as proof of your participation.

Overall this course has been in development for 16 months and we’re hopeful you’ll be able to see the attention to detail we put into it.

I hope you find this news as exciting as I do. Please help me out by spreading the word to your friends, coworkers, grandmothers, and anyone else who might be interested. Thank you.

Das Team ist das zentrale Element in Scrum. Die Chance, über effektive Teamarbeit Synergie zu kreieren, ist allerdings von verschiedenen Variablen abhängig, unter anderem auch von der schnellen und gezielten Entwicklung des jeweiligen Teams. Definierte Teams gestalten immer von sich aus ihren, meist unbewussten, Arbeits- und Sozialprozess, der jedoch durch gesteuerte Teamentwicklung schneller und effizienter verlaufen kann.

Teamentwicklung ist definiert als die gezielte Einwirkung auf die komplexen, offenen und verdeckten Prozesse eines definierten Teams, bezogen auf die Aufgabenstellung, das Struktur- und Beziehungsgefüge und die einzelnen Teammitglieder, zur Optimierung von Arbeitsfähigkeit und Effizienz und der Bearbeitung aktueller Blockaden.

Gezielte Teamentwicklung gehört zu den Aufgaben des ScrumMasters, der zur Gestaltung und Umsetzung differenzierte Modelle und Methoden braucht. Ein effektives Instrument in der Teamentwicklung ist das Modell der „Drei Grundwerte sozialer Systeme“ Dieses Modell eignet sich optimal zur Teamprozessanalyse und kann die zentralen Elemente von Dynamiken und Prozessen im Team darstellen

Das Modell der drei Grundwerte

Es ist ein systemisches „Urmodell“, das in vielen Kulturen in ähnlicher Ausprägung vorkommt, und aussagt, dass in allen vorfindbaren sozialen Systemen (Teams) dieses Set der Grundwerte Wissen/Know-how, Ordnung/Struktur, Vertrauen/Beziehung als vorgegeben existiert: Diese Grundwerte sind von zentraler Bedeutung für den Prozess der Selbstorganisation des Systems (Teams). Die zentrale Botschaft dabei ist, dass jeder dieser drei Werte im Team gewürdigt, gelebt und fließend entwickelt werden muss. Sind diese drei Werte in ausgewogener Balance, bedeutet dies für Teams Stabilität und Lebensenergie im Sinne effektiver Selbstorganisation. Entsteht eine Dynamik von Dis-Balance, d.h. ein Wert dominiert überproportional bzw. ein Wert ist sehr schwach ausgeprägt, erleben Teams diesen Zustand als z.T. massive Störung.

• Wissen/Know how stärkt Teams in der Bewältigung fachlicher Anforderungen, im Umgang mit Arbeitsstrukturen und –prozessen und dient sowohl der Gegenwarts- als auch der Zukunftssicherung.
• Ordnung/Struktur schafft zentrale Regularien zur  Orientierung und Handlungssicherheit. Neben Regeln und Prozessen sind Hierarchie und Führung zwingend notwendige Ordnungselemente.
• Vertrauen/Beziehung gestaltet das soziale Miteinander im Sinne von Klima, Wir-Gefühl, persönlichem Schutz und Sicherheit und Zugehörigkeit.

Der ScrumMaster in der Teamentwicklerfunktion kann daraus ein Prozessanalyseschema ableiten, das ihm und dem Team ermöglicht, z.B. in Retrospektiven oder Teamentwicklungsworkshops den Ist-Stand zu definieren und Entwicklungsfelder abzuleiten.

Ein Teamentwicklungsprofil könnte z.B. folgendermaßen aussehen:

Jedes Team hat ein individuelles Profil, das sich aus der Ausstattung und dem Zusammenwirken der Grundwerte gut ableiten lässt. Dieses Profil kann der ScrumMaster für sich als Beobachtungs- und Diagnoseinstrument entwickeln und nutzen, aber auch mit dem Team gemeinsam er- und bearbeiten. Der Prozess mit einer konsensorientierten Reflexion und Festlegung des Ist- Standes des Teams zwischen den Polen 1 und 10 und der Definition von Entwicklungsfeldern setzt eine fruchtbaren Dialog in Gang und ist damit Teamentwicklung par excellence. Die einzelnen Elemente jedes Grundwertes sind hier beispielhaft dargelegt und können je nach Praxissituation ergänzt werden.

Dieter Rösner, Trainer ScrumMaster Pro

Related posts:

1. Der klassische Projektmanager in Scrum
2. ScrumMaster Pro – TeamDevelopment
3. Was macht Scrum Teams eigentlich hyperproduktiv?

I was talking recently with a friend about separate retrospectives for sub-groups. They were worried about thing devolving into separate silos, with a retrospective for programmers, a retrospective for testers, a retrospective for analysts, …. I would be worried if that happened, too, but I can see value in separate retrospectives. How can we know when they’re appropriate and when they’re not?

I’ve led a separate retrospective for developers (programmers and testers) at a client making an Agile transition. In that situation, it seemed to me that the full-team retrospective concentrated on “acceptable” improvements—things that were easy to propose in a corporate environment. And I noticed that a number of the developers didn’t say volunteer anything. That was a clue to me that there were things to be said that people didn’t feel comfortable saying. Given the fact that the Scrummaster was a former project manager, this dynamic wasn’t unexpected. Having a separate retrospective, with a safety exercise at the beginning, allowed some issues to be acknowledged, even if they weren’t tackled.

In my friends situation, the majority of the participants are programmers who have, for the most part, worked with each other at other companies. They know each other well and are working together at this company precisely because they get along and respect each other. That’s all well and good, but the side effect is that there’s a bit of a monoculture among these developers. They readily agree with each other within a limited viewpoint.

You would think that a retrospective would bring out other viewpoints and counteract the hegemony of this group. Unfortunately, the group had settled on “majority vote” as their standard means of deciding which topics to pursue in the retrospective. How did they choose that? I don’t know, but I’d guess they voted. Ellen Gottesdiener examines a number of group decision-making approaches in her article “Decide How to Decide.” (Software Development Magazine, January 2001) While majority vote is fast and efficient, it always results in a loser, and sometimes in a persistent loser. For retrospectives, I prefer “Spontaneous Agreement” or “Consensus.” When the group I’m facilitating can’t converge on a choice that hears all voices, I’ll sometimes fall back on “Decision Leader Decides After Discussion” to give those voices a chance.

If you’re stuck in this sort of situation and you’re not the facilitator or otherwise capable of making the decision, then feedback to the retrospective facilitator might be in order. It could be that the facilitator just hasn’t noticed what is happening. It could also be that the facilitator doesn’t yet have the skills to know what to do about the retrospective being consistently owned by a sub-group. Some helpful feedback, stated in terms of observed behavior and personal impact, might be just the thing to break that log-jam. Or, it might not, particularly when there’s a difference in organizational power between the facilitator and the person who wants to help the situation.

Having a separate retrospective of people locked out of the decision-making in the larger retrospective is an escalation of this approach. If one person has been unable to influence the facilitator’s behavior such that all voices are heard, perhaps the group of disadvantaged people can dig deeper into the problem and come up with some more effective solutions. If this group continues to feel the need for a separate retrospective, though, then it indicates a continuing problem.

That’s not a good sign for the organization. Human dynamics of a given group don’t always work out smoothly. And sometimes organizations fail.  Being deaf to voices have different information, values, or preferences is a good way to fail. The universe doesn’t depend on every organization succeeding. As an individual, there’s always Martin Fowler’s advice, “Change your organization, or change your organization.“

Since the late 19th century when Marconi started patenting other people’s ideas innovation stopped being collaborative and become competitive. The competitive culture spread top down, introducing formality and controlling methods to keep the top at the top and those at the bottom doing what they were told. In the 21st century agile teams are challenging the status quo and changing the way we think about work. For anything to grow it needs a friendly environment giving it the strength to fight off predators. In this post I look at the various environments we work in both real and in my dreams and assess which provide the sustenance for Agile to grow and spread.

Agile Team (real)

In traditional corporate culture when software projects fail Managers turn to the team in an attempt to find something or somebody to blame. When the smart team, who spend their time learning about better ways of doing their job rather than looking for people to blame, tell their manager they have a better way they are often given the opportunity to try. Motivated by this freedom it’s not hard to make an improvement. A smart organisation will take note of this and begin to learn from the underlings. A dumb one will protect their positions with lame excuses and continue as before until their business goes extinct and their smart developers move on. #limitedwin

Agile Collective/Cooperative (imaginary?)

A group of like-minded agile developers, read @ericries,  start a collective, build something great, disrupt a market, except no outside money, sell out, do it all over again. It’s the rock’n'roll of software development . Agile spreads by natural selection as they wipe out their competitors one by one #yesplease  (until the bigcorp realises whats happening and uses their huge muscle to crush them #horriblereality) 

Not very Agile Startups (very real)

Started by some opportunist entrepreneur and funded by short-term VC’s the pressure is huge. Agile dies a swift death. The startup will probably get sold to Tesco or meet some equally horrible fate #fail

Agile Corporation (maybe one day)

Big corp have the money to bring in smart people to help them beat the competition. They struggle to change but may just have the vision and determination to see it through. Unfortunately the divine right of the shareholder forces them to focus on short-term cost cutting and mass redundancies destroy the good work. It takes time to develop teams that collaborate well and this requires some stability #likelyfail

So where can we find happiness at work?

Well it’s a hostile environment out there for a fun-loving, segment disrupting agilista, but we’ve been fighting the status quo too long to give up. What options do we have to change our environment?

Revolution

Ok so lets build an army and take up arms against the evil fat cats? No? OK then #fail

Education

Lets replace Religious Education (R.E.) with the missing link in human evolution “Collaboration and Facilitation Education (C.a.F.E)”. Apart from improving the workplace, C.a.F.E could help in other important areas such as World Peace and Family Breakdowns #terawin. All the money saved could go toward building an enormous icon of Jeff Sutherland (see pic) #fail

Enough (Conclusion)

This post may be tongue-in-cheek but the problem is real. We need to keep things simple, the problem may be complex but the solution doesn’t have to be. Agile makes work satisfying because we become effective and brings happiness because we are fulfilling a human desire to collaborate. We only ask for a simple change that: Teams have a fundamental right to determine their own way of working and we can take it from there.

iceScrum est d’abord un outil Scrum, on y retrouve naturellement les 3 rôles majeurs que sont le Product Owner, le ScrumMaster et le membre de l’équipe, qu’on appelle aussi Développeur.

Une équipe de développement est donc composée de Développeurs (DEV) et parmi eux d’un ScrumMaster (SM) et d’un Product Owner (PO).

Il est d’usage d’appeler StakeHolders (SH) les personnes qui sont intéressées par les résultats de ce que fait l’équipe, mais qui ne réalisent pas eux-mêmes le travail. Comme un de piliers de Scrum est la transparence, un SH voit ce que fait l’équipe.

Lire la suite de l’article.

The call for speakers is open for fourth Lean Agile Scrum Conference in Zurich on September 12.

This year's conference features keynote speakers Joe Justice (initiator of Wikispeed) and Roman Pichler (author of Agile Product Management with Scrum: Creating Products that Customers Love)

Under the motto, 'Products, not projects" the organizers, the SwissICT „Lean, Agile & Scrum“ group, once again seek to bridge the gap between C-level executives, managers, project leaders, business analysts, developers, and testers and connect the management perspective with the view from the trenches.

Read the full announcement on the LAS homepage  (or in German) or jump directly to the submission form.

Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members. I don’t advocate this, as I don’t think it demonstrates an appropriate respect for the challenges and significance of the role. In my family, we rotate who cleans the table and loads the dishwasher. Any of us can do that job. We do not, however, rotate who cooks dinner. My wife is a far better cook than anyone else in the family. We want the cooking to be the best it can be, so we don’t rotate that job. If you want your Scrum team to be the best it can be, I do not recommend that you make a habit of rotating the job of ScrumMaster.

However, there are some occasions when you may want to rotate. The most common is when you want to create learning opportunities. For example, if team members are struggling to understand the duties of the ScrumMaster, they may want to consider rotating each team member through the role. This may allow each to develop an understanding of what it means to be a ScrumMaster. Similarly, if a team identifies four or five good ScrumMaster candidates among their ranks, it may want to rotate among them, giving each a chance to try the role. Then by considering the performance of each, the team will hopefully be able to choose the most appropriate ScrumMaster.

Bob Schatz and Ibrahim Abdelshafi of Primavera Systems point out another reason why rotating might be useful.

With time the team can begin to treat this position as their manager. And the person in that position typically detects and dutifully fills the apparent need. The result is a breakdown in the team’s self-management practice. By rotating the responsibility at the start of each sprint, it diffuses the role and makes it a shared team responsibility and establishes a balance of power. (The Agile Marathon in the Proceedings of Agile 2006)

So, although it is possible to rotate the job of ScrumMaster, I recommend doing it only for specific reasons, such as those just given, and only temporarily. Rotating should not be a permanent practice. There are simply too many problems with it, including the following:

• Someone who has rotated into the role usually has other, non-ScrumMaster tasks to perform during the sprint, and these often take priority.
• It’s hard to train enough people to do the role well.
• Some people will use their time as ScrumMaster to try to push through changes to the process.
• Designating someone as ScrumMaster for a sprint or two does not automatically make someone value the job, which can lead to ScrumMasters who think Scrum is a mistake.

Pour démarrer rapidement avec iceScrum dans le but de le tester, une façon simple est d’installer le « bundle » (il y a encore plus simple : allez sur iceScrum Cloud).

Pré-requis :

• Machine Virtuelle Java (JVM) 1.6 ou supérieure : JDK installée, avec les variables JAVA_HOME ou JAVA_JRE présentes et indiquant le chemin (vers la JDK pour JAVA_HOME)
• Navigateurs internet : InternetExplorer 7+, Firefox 3+, Safari 3+, Chrome

Installation :

1. Téléchargez la dernière version du bundle.
2. Décompressez-le dans le dossier de votre choix.
3. Ouvrez ce dossier.
4. Dans le fichier config.properties, changez : grails.serverURL = http://[url_to_icescrum]/[context_name] (par défaut c’est http://localhost:8080/icescrum)
   
5. Exécutez le fichier « start.bat » sous Windows ou lancez « start.sh »  dans un terminal sous Unix/Linux (et Mac). Vérifiez les droits d’exécution (sous Unix, faire un chmod u+x *.sh dans les répertoires bundle et bundle/server/bin) et l’ouverture du port 8080.
6. Dans votre navigateur, tapez l’URL : http://[host_adress]/[web-app] (par exemple, http://localhost:8080/icescrum).
7. Il ne vous reste plus qu’à vous enregistrer : cliquez sur le bouton « S’enregistrer », remplissez le formulaire et validez. Vous pouvez maintenant créer un projet.

L’utilisation du bundle ne constitue pas une installation pérenne, elle doit être réservée à des fins de test.

Veuillez noter que l’utilisateur lançant le serveur Tomcat doit posséder les droits d’écriture sur dossier Tomcat.