Stories in Pivotal Tracker have been given a serious upgrade. For the most part it’s all pretty self explanatory - the functionality you’re used to is all there, just in a format that’s more intuitive, user friendly and hopefully you’ll agree, more appealing. Our advice, play with it and then come back and read the rest of this post, especially if anything is confusing.

You’re back, so let’s continue!

One of the goals of Tracker has always been to make collaboration around your story backlog as easy as possible, so that your team spends less time managing your project and more of it actually building things. We think there’s room to make that not just easier, but more enjoyable, even fun! So to that end, great usability and user experience are major themes in our backlog for 2012, starting with this story redesign.

See below for all the highlights.

New Look and Feel

Like we said, stories look different, and are hopefully a lot easier to work with now. It's a complete redesign, with a color scheme that fits better with the rest of the Tracker UI, and that's intended to make the important information in a story stand out more - such as the story title, description, comments, code commits, and file attachments.

Besides visual appeal, we’re aiming to reduce clicks - for example, when creating a new story, it only takes one click to choose a story type or point estimate value. And, you can now start, finish, deliver, or accept/reject an expanded story with one click, with the familiar buttons.

Click to Copy ID and Story URL

We heard your feedback about having to scroll down in stories to find their IDs, to copy them to your commit messages (you are using the source commit integration, right?). So, we've moved the ID to the top of stories, and made it so that you can copy the ID to the clipboard with one click (on the ID button).

The same is true for the story URL, for when you need to send someone a link to the story. Just click the link button in the top left corner, and the story's full URL will be copied to the clipboard. Note - you’ll need Flash enabled in your browser for these to work. If you don’t have Flash, you’ll see the full URL on a separate line, so you can copy it the old way.

Less commonly used actions, including delete and view history, have been moved to the “More” menu, which is where we’ll be adding some other convenience actions soon.

File Attachments on Comments

One big change in this redesign is that files are now attached to stories as part of posting a comment, rather than as a separate list. This is because files are commonly uploaded and shared in the context of an on-going conversation, and it’s so much easier to refer to a file that’s actually part of that comment (e.g. “Here’s that icon”) rather than having to say “see the file named foo.gif at the bottom of the story”.

You can still drag and drop files from your desktop to stories, and entering an actual comment when adding files is optional - just drop your files on a story and close it.

View All Images and Comment Filtering

The truth is, thumbnails of mockups attached to a story can be indistinguishable from one another. Sometimes you just need to see them all full sized, on one page. Now, with just one click of the View All Images link above the Activity section, you can.

We’ve also made it easier to find what you need in a long-winded (all of it beautifully clear and vital) comment conversation - just use the filter dropdown menu at the top right of the Activity section to show just file attachments, just source commits, or all comments without commits.

Feedback

This redesign of stories is the first step in an on-going usability overhaul. We’ve got much more coming over the course of this year, but we’d like to incorporate your feedback at every step, so please let us know what you think so far, in the comments here or by email to tracker@pivotallabs.com.

It’s 2012, everyone is back in the groove after December holidays, so it’s time to get the circles going again. We will be kicking off on Monday 13 February, atLots are people are asking me about coaching circles. How was the retro, when are they starting up again, can they join, etc. I though it might be time for a post.

Retrospective

Last year ended with a great retrospective on the final round of coaching circles, facilitated by Cara Turner. This was the first round of circles where we split into 3 types: mentoring, coaching and dojo. It seems the end result was very positive. People loved the new circle types! See the photo’s below for the outcomes of the retro.

 

 

 

First we made some posters about the sessions.

 

 

 

 

 

 

Then we talked about things we didn’t like (burnt toast), things we loved (ice cream) and things we’d like to try (experiments)

 

 

 

 

 

 

 

 

In the end we had some suggestions and next steps actions

 

Onwards and upwards

It’s 2012, everyone is back in the groove after December holidays, so it’s time to get the circles going again. We will be kicking off on Monday 13 February, at 6pm. Please signup if you will attend. If you are keen to join a circle or even just find out more about them to decide if they are right for you, then make sure you get yourself to the kickoff. As always those who can’t attend the kickoff may still join circles by adding their details to the coaching circles google doc. However please note, those at the kickoff get first preference for circles of their choosing. Also for newbie, it’s highly recommended you come to the kick off to get an idea of what’s involved and how it works. Remember we will need hosts who can offer venues, signup in the google doc if you can offer one.

Signup for the kickoff here!

 

First of all, the fact that I am only blogging about last months event, a mere two hours from the start of this months event, is definite grounds for an apology! Better late than never they say?

The first Thursday in December. Four confident looking presenters got themselves geared up. No walk in the park this. Each presenter had only 6 minutes to get their message across. Each slide had to be no longer than 20 seconds. What I didn’t know, until that evening, was that each slide had to automatically be set to transition after 20 seconds. No pressure!

First up was Sheetal Gordhan. Scrum is not for the faint hearted was her topic!

I’m looking at my notes now, and I see the Ken Schwaber quote: “Scrum is hard”. And right next to that I have Sheetal paraphase: “This kak is hard”. I like Sheetal’s version I remember us all having a good chuckle, leaned back in our seats and took in a nice big gulp on our drinks. Our evening was set, we were here to have some fun!

Sheetal’s presentation reminded us that only a small percentage of teams are actually successful in Scrum. It’s really not easy and we need to prepare ourselves when we embark on this journey. Even though there are 1,000′s of articles online, it’s still not enough to prepare us for what lies ahead.

I can honestly say that I, in 6 minutes, had learned more about what a newbie organisation to Scrum should expect than I have in any course attended or article read.

My favourite slide of Sheetal’s. Hmmm, this is a tough one, there are so many. I liked the Google statistics of how many results one can expect when searching for Scrum information. But one that really stood out for me was the All Blacks doing the haka. Titled ‘Scrum Rituals’.( Remember, this event was in early December, only a few weeks after the All Blacks were crowned World Champs!). What are your development teams rituals? The usual stand-up and retrospective, or do you have something unique?

Next up was Meloné van Heerden, with her presentation entitled, What makes a great leader. Meloné had recently attended a course on this subject, and used the opportunity to apply her learning’s into the software development, in particular, Scrum, environment. One could see that the learning’s had a big impact of her, as her talk was passionate and energetic.

The subject of an ‘authentic leader’. What is an authentic leader? Or rather, what makes a leader authentic? Mel took us through the 6 step of process of discovering the authentic ‘you’. A necessary self-awareness process. A look at intrinsic and extrinsic motivators.

My favourite slide of Meloné’s. I personally liked the way in which she modelled the need to effectively set a leadership example, with well-known figures. Nelson Mandela and Barrack Obama featured, with Obama’s family an example of how important it is to build a support network. But my favourite would have to be a slide which represented who we sometimes don’t change. Any guess who features? Have a look at the photo below.

Next up, the good man David Campey. David had an interesting approach. Each of his slides represented a photo he had taken of his agile working environment. We got to meet his team. His manager. His Product Owner.

It told a story of a project. Starting from a photo of his Product Owner, looking very visionary in a room with blue-sky type walls, through to photo’s of his team hard at planning, and ending with his team out on a boat trip

I’ve always found it fascinating to see how other organisations work. How they approach their Scrum repertoire. Especially local companies.

David’s presentation was recorded, so please have a look for yourself. I’ve already sent this out to my development teams. Motivational stuff!

And finally, Karen Greaves, who needed little introduction off course! Her talk was titled: “Agile Management: How to create a culture to help your team succeed.” It was awesome! Need I say more. Who thought a talk about management could be fun

Thank you to everyone that attended. And a big thank you to our four brave presenters. You were all superstars!

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.

We are a middle-sized organization of coaches, consultants and developers – and we see ourselves Agile and Lean through and through, to the core, dyed-in-the-wool, born-and-bread. Well, to be honest, we might be not. Or at least not from the beginning. Over the years, we learned a lot: * How to have self-organizing teams * How to manage our acquisitions and changes with Kanban boards * How to improve our communication with social media * How to distribute power and responsibility in a company owned by their employees And we’re not done learning yet. ...

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.

We've got a major update of Pivotal Tracker planned for this weekend, which requires downtime while we run a fairly major database schema migration.

The update is planned for Saturday, Feb. 4, at 9:00 Pacific Standard Time (PST), or 17:00 UTC, and we expect it to take approximately one hour.

Apologies for the inconvenience, but we're hopeful that you'll like what we're rolling out!

For real time status updates, please follow @pivotaltracker on Twitter.

Two words, Agile and coaching, seem to be the most-used buzzwords (after brain and neuro) of the last five years or so. The way things are progressing, I see them staying at the top of the list for decades.

This article focuses on the obstacles to using Agile in a distributed team environment and recommends how to counter them with what is called “de-Agile.” De-Agile is tailoring Agile to fit your team by taking out processes that don’t make sense and tweaking those that need to be modified to suit your needs. In a distributed team environment, de-Agile is mostly about removing the sense of being distributed. You need to educate each team member about the additional communication responsibilities required when working with remote team members and emphasize the ...

Introduction

Setting up Git can be intimidating, especially for those that are trying a version control system for the first time or moving from Subversion. It used to be the case that Git was a huge hassle to install and use on Windows. However, nowadays it's super easy to use Git on Windows either through Git Bash, if you're a fan of the command line, or if you prefer a graphical interface, through programs like TortoiseGit. Below we'll show you how to set everything up and connect it with Assembla.

Note: Below is a condensed version that doesnt show EVERY screenshot along the way. For the long version, click here.

Table of Contents

1. Download and Install Git for Windows
2. Download and Install TortoiseGit (Optional but recommended for first timers)
3. Generate SSH keys
4. Link SSH key with Assembla

Prerequisites

1. Assembla Git repository - sign up if you haven't already, it's totally free for standalone Git hosting.
2. A strong desire to install Git on Windows.
3. That's it, let's go!

1. Download and Install Git for Windows

To get things started, you'll need to download and install Git for Windows. You can download it here. If you're unsure of which one to choose, just go with the full installer. After downloading, run the installer.

 
If you have PuTTY/TortoiseSVN installed, you may see this screen, otherwise just ignore this. Regardless, use OpenSSH to make things easy. 
 

Download and Install TortoiseGit

This step is optional. If you are comfortable using the command line for interacting with Git, you do not need to install TortoiseGit.

Next up, let's download and install TortoiseGit.
 

We'll need to configure TortoiseGit - to do this, right click anywhere on your Desktop, select "TortoiseGit" and then "Settings."


Find "Git" and then click on "Config" from the menu on the left. Then fill in your Name and Email, making sure to use the same email that you used to sign up for Assembla.

Don't forget to click OK when you're done.
 


Great, now TortoiseGit is all set! Generate SSH keys

There's two ways to generate SSH keys:
  1. If you installed TortoiseGit, use the method directly below. 2. If you only installed Git on Windows and are not using TortiseGit, jump to the "Git Bash SSH Keys" section.

TortoiseGit SSH Keys

SSH creates a secure connection from your computer to Assembla, making sure that you are who you claim to be so that only authorized persons can commit to your repository. Assembla needs to know your public SSH key to make the secure connection, so let's fire up Puttygen to generate an SSH key pair.

Start -> Programs -> TortoiseGit -> Puttygen


In Puttygen, first click on the "Generate" button.


Next, you'll move your mouse around the big gray area under the progress bar to generate randomness for super security.


Once the key is generated, you should copy it onto your clipboard. You'll use this later to authenticate with Assembla.


Afterwards, choose a memorable password and confirm it. Don't forget your password!


Lastly, click on the "Save private key" button and save your private key somewhere you'll remember.

Git Bash SSH Keys If you did not install TortoiseGit, you're at the right place! If you did install TortoiseGit, follow the steps above and skip this section.

• Start up Git Bash: Start -> All Programs -> Git -> Git Bash
• On the command prompt, type in the following command substituting with the email you used to sign up for Assembla.
• When it asks you for the file, just hit Enter.
• Please note that you should definitely enter a passphrase; when you type, nothing will show up. This is normal, don't worry about it.

ssh-keygen -t rsa -C "me@email.com"

Use Notepad to open up the .ssh/id_rsa.pub file you just generated and copy the all of the contents of that file.

Link Your SSH key with Assembla Open up your Assembla profile which is where you'll paste the public key you just copied from the previous step. 
 
Click "Add Key" after you've pasted the key into the box. You should see something like the following picture below. If so, congratulations, you're done with this section!
  Create Something! Now the fun begins! Click here to learn how to clone your git repository, add files, commit, and push.  
Stuck? Need help? If you encounter difficulty with any of this, don't hesitate to contact Assembla support.

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.

Daniel Greening, former Director of Engineering Productivity and User Experience at Citrix, will be delivering Scrum.org's second Agile Webcast Series event on Tuesday, February 7th, 11:00am-12:00pm, completely free to you.

In Release Duration and Enterprise Agility, Daniel explores how the adoption of Scrum and Agile by the example company, Citrix Online, drove release duration down from a peak of 41 months to less than 4, better than what it had as a small startup. Its market share rose during the same period.

Data from another company, PatientKeeper, also seems to indicate that short release durations correlate with more profitable outcomes. Learn about all the benefits of short release durations in this free webcast.

Space is limited. Register soon.

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