I didn’t know at the time but Google also allows you do something similar. You just need to go to http://www.google.ca/experimental/ (also works for google.com and I guess most other domains). There you can opt-in to be part of the Keyboard shortcuts experiment. That’s it! J/K are used to navigate through search results, O (or enter) to open them.

Hopefully this is going to be useful for the other keyboard junkies out there.

http://visualstudiomagazine.com/Articles/2010/07/27/Installing-Scrum-Process-Template.aspx

Urban Turtle 3.2 fully supports the new Visual Studio Scrum 1.0 Process Template. Using the index card metaphor with drag-and-drop functionality, it is the perfect replacement for Excel-based planning workbooks.

Tweet This Post

So you have initiated an Agile transition and have faced some resistance to change! Or maybe, you assessed your current level of Agile Maturity and are hoping to achieve the next level. Better yet, you and your team are planning to launch an Agile transition that is not driven by the wrong reasons.

That’s great!

If you haven’t already done so, you may want to read: Getting Started – Reference Material for Managers Who Wish to Understand Agile and Scrum and What consultants don’t tell you before you begin an agile transition.

Let’s cut the chase and get to the point. Are you ready? Here it is. The secret to a successful Agile Transition -> Make people look good!

Yes. That’s it. Surprised?

I’m not talking about psychological manipulation. I’m talking about finding what drives the people you are working with and the managers around them and then capitalize on their drivers in order to get them to get on board with the transition – and better yet become evangelist for your transition. Here are some examples:

• Suzy is hoping to get promoted to Vice-president within her organization. She heads a business line from which you need support and a dedicated Product Owner. Why don’t you explain to Suzy how innovative her group would appear to others if she agreed to embark on the Agile initiative?
• Peter is struggling to increase the performance of his group. So far, he hasn’t shown much interest in the transition but you found out that he has been under high pressure from his manager to increase the performance of his team. Why wouldn’t you show Peter how using an Agile approach could help get his manager off his back?
• Monica is a project manager who has lost several key people in previous months. She is usually by-the-book (i.e. PMBoK) but during a recent lunch, she admitted that she would be willing to try something different if only it would help her retain the contributors she needs to make her project successful. Why don’t you take this opportunity to get the project manager on board with Agile by offering to help her?

Don’t get me wrong. I am not asking you to lie, to cheat or to fake the objectives and expected outcome. I’m telling you to get others on board and working WITH you by telling them the whole story and helping them understand that there is something in it for THEM too.

Agile relies heavily on communications and interactions. Why don’t you start with all the people directly and indirectly impacted by the transition? Sure, it will require more time in the short term to influence people into supporting you but in the long run, you will be glad you did it.

Go ahead. Try to figure out what drives people around you or what issues they are facing. Find a solution that can help them and you’ll end-up with a win-win scenario and a successful transition.

You might be interested in these related posts:

1. Agile Transition – What about the teams outside the transition?
2. Book review: Outliers: The Story of Success
3. What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers

Monday : I decided to use Typeracer as my baseline. It’s an online game that allows you to race others. The fastest typist wins. I had not played in 6 months or so – and it showed. My score for the last ten races dropped a bit. This was not a good start. Result after the day : 74 wpm

Tuestday : I did some drills on goodtyping.com to get back to speed. It must have helped because I raised my speed to 78 wpm.

Wednesday : mostly played Typeracer. I managed to cut down on typing errors and I’m up to 81 wpm.

Thursday : I tried to practice at night instead of during lunch time. Without much success – 80 wpm. My fingers were not obeying me. I did a few drills on goodtyping.com to increase accuracy.

Friday : Success! I managed to consistently type over 80 wpm today by concentrating on typing slower but with less mistakes. I managed an average of 87 wpm on my last 10 races.

The week is over and I achieved my objective of 85 wpm. I did this mostly by reducing mistakes – they can get really slow you down.

Thanks to my colleagues who followed in my track and helped me focus on this challenge.

Look at the interface yourself.

They added a dummy deprecated method called _dont_implement_Matcher___instead_extend_BaseMatcher_ in the interface.

I am still unsure whether I will ever use this in my own projects. But when this method appeared in my code today I could not help but look at it. It was then totally clear that I was not doing what they wanted me to do. I’ve seldom seen documentation that obvious.

This first year was mainly spent:

• in dispatching features by theme in dedicated modules
• in integrating different mechanisms
  • to install/uninstall Minyaa with its code intrusions in JIRA
  • to manage licences to access different modules of Minyaa
  • to process background upgrades
• in enhancing existing features in terms of User Interface
  • Workflow Functions (Conditions, Validators and Post),
  • Auto Transition Service,
  • …
• in following all big changes occurred with JIRA 4.x:
  • New Licence Structure based on user limit
  • Migration from Portlet to Atlassian Gadgets
  • New Starter program: 10$ for 10 users
• in extending Minyaa Time’s report with any type of Fields
• in extending Minyaa Workflows with a Workflow Designer able to:
  • provide a graphical way to define your workflows
  • integrate more features provided by OSWorkflow (Common Transitions, Global Transition, Recursive Transition)
• in assisting you in the adoption of Minyaa, which is easier to install than Kaamelot when the procedure is followed, but can be difficult when a step is skipped.

Next year, we will concentrate on the following:

• ERADICATE most intrusions performed by Minyaa, in order to:
  • simplify its installation
  • support the UPM (Universal Plugin Manager)
  • perhaps support JIRA Studio (this will be a challenge!)
  • stop making the Atlassian Support guys crazy about Minyaa
• Continue to enhance Minyaa Workflows’s features (OSWorkflow has again some useful mechanisms)
• Extend Minyaa Time with new features (wait and see!)
• Integrate Myrddin plugin  in Minyaa Projects (Don’t try finding it… It was developed at the same time as Kaamelot, but was never released.)
• And always assist you in the adoption of Minyaa

Happy Birthday Minyaa!

A few weeks ago I referred to Daniel Pink’s book (Drive: The Surprising Truth About What Motivates Us) to show how autonomy, mastery, and purpose greatly impact people’s motivation and how we can use these dimensions to help in an Agile transition.

Today’s post is about Alessia and her painting.

Alessia is a happy 9 year old girl. She is self motivated when it comes to painting. She always:

• gets up on time for her Saturday morning classes;
• is anxious to go to her classes;
• is learning quickly and
• does very nice work.

If you have young children, you certainly already know how difficult it is to get them to do something they don’t want to do – pick up their clothes, get up on time, hang their towel after their shower, etc. But when kids are self-motivated, things are completely different. Don’t you find?

Grown-ups aren’t much different. When people are told to do things or are assigned tasks, the quality of the work can’t be as optimal as when THEY decide to do it. Not only isn’t the quality as good but the amount of energy required to deliver the task is much higher than if the individual wanted to do it in the first place.

Granted, relying on self-motivation requires people managers to come up with ways to make the tasks interesting or fun, or they can also rely on the concept of Autonomy (or self-organized teams) which is so strongly emphasized with Agile.

Needless to say, if kids can self-organize and be self-motivated, so can grown-ups. All they need is the right environment to do so.

I am proud of my daughter

Don’t worry Giordano, daddy will write a post about you too

You might be interested in these related posts:

1. The kids are having a great time at Sportmax
2. Timmy's story: Is it better to be right or to be helpful?
3. More time does not create better decisions

Since Minyaa 2.0, a new Workflow Designer allows you to create more easily Workflows using a graphical tool and giving the ability to use some unreachable features provided by OSWorkflow, library used by JIRA to manage workflows.

When you open JIRA for the first time, you discover the generic workflow :

• 5 Steps : Open, In Progress, Resolved, Closed and Reopened
• 7 Transitions : Create Issue, Start Progress, Stop Progress, Resolve Issue, Close Issue, Close (Resolved) Issue and Reopen Issue

Using the default Workflow Editor (HTML based), you see them as demonstrated below:

Default JIRA Workflow

There are 2 Close Issue transitions, but when you try to produce the same Workflow using the default editor, you are not able to create 2 transitions with the same name.
There are 4 transitions reachable from different Steps, but always trying to do the same with default editor, you are not able to reproduce it.

After reading JIRA documentation and different JIRA Community contributions, you will discover that you have to use XML language to reproduce the default JIRA Workflow!

If you open the default JIRA Workflow with Minyaa Workflow Designer, you will obtain the view below:

Default JIRA Workflow view with Minyaa Workflow Designer

You will have a better view of existing interactions between the different Steps and Transitions.

Many companies consider JIRA as an inexpensive tool to implement workflow for some of their processes … Fine ! But their processes are not always simple ones, and by using the default JIRA Workflow Editor, some of them may obtain something incomprehensible as showed below:

Workflow XXL (Very large Workflow built with JIRA)

Edited with the JIRA Default Workflow Editor, this workflow needs more than 5 pages of your Browser ! Even when edited with the Minyaa Workflow editor, this workflow is still too large to be used easily.

This Workflow has 28 Steps and 141 Transitions … an XXL Workflow !

If we take a deeper look inside this Workflow, we will be able to identify some Transitions candidate to be defined as Common Transition or perhaps as Global Transition, and/or qualified as Recursive Transition, but also some exotic practices :

• 20 Cancel Transitions to step Cancelled :
  • 4 allowed to all Users
  • 1 reserved to the Reporter + Screen
  • 1 reserved to the Reporter or Project Roles (10002,10031)
  • 14 reserved to Project Roles (10002,10031)
• 6 Reject Transitions to step Rejected :
  • 1 reserved to the Reporter or Project Roles (10002,10030,10031)
  • 4 reserved to the Reporter or Project Roles (10002,10031)
  • 1 allowed to all users

• 12 Request More Info Transitions
  • 1 reserved to the Reporter or Project Roles (10002,10030,10031)
  • 11 reserved to the Reporter or Project Roles (10000)
    • 6 Transitions to step Deployment – Pending Info
    • 5 Transitions to other different Steps

• 9 Edit Transitions (All recursives)
• 11 Put on Hold Transitions
• 18 Enter Info Transitions
  • 6 Transitions from Pending Info (each of them with a condition to return to previous step), but Pending Info is never reachable (It appears that it was an aborted try!)

  <condition type="class">
     <arg name="jira.previousstatus">Deployment - Upload Verification</arg>
     <arg name="class.name">com.innovalog.jmwe.plugins.conditions.PreviousStatusCondition</arg>
     <arg name="jira.mostRecentStatusOnly">yes</arg>
  </condition>

  • 6 Transitions from Deployment – Pending Info (each of them with a condition in order to return previous step)
  • 6 Transitions from different step, always returning to previous Step
• 4 Activate Transitions
  • 2 Transitions are strictly identical
  • 2 Transitions differs just by a Post-Function
• 13 Reschedule Transitions

As you see, most of these 93 Transitions may be assumed duplicated. When you have to define complex workflow, JIRA allows to create Step Transition only, and not Common Transition.

Editing workflows with XML may allow you to use Common Transition, but in this current example, the associated XML file has more 6000 lines !

Minyaa Workflow allows to declare Common Transitions, Global Transitions and qualify them as Recursive Transition, without using XML syntax.

To be honest, Minyaa Workflow Designer (developed in Flex) has encountered its current limits with this workflow when we tried to refactorize it. We will have to enhance its performance.

But in order to see what this workdlow would be, if it was created directly with the Minyaa Workflow Designer,  its re-factorization has been done manually through XML.

We are obtaining the following Transitions :

• 4 Cancel Transition
• 3 Reject Transition
• 7 Request More Info Transition
• 1 Edit Transition qualified as Recursive Transition
• 1 Put on Hold Transitions
• 1 Enter Info Transition with the Post-Function : Back to Previous Step
• 3 Activate Transitions (potentially only 2)
• 1 Reschedule Transitions

Just by using Common Transition and the Back to Previous Step Post-Function provided by Minyaa Workflows (release 2.1), the workflow has now 60 Transitions (21 Common Transitions) and 22 Steps. It is now a XL Workflow.

Workflow XL

The above screenshot is excruciatingly painful to read… From 93 Transitions identified as possible duplication, there are now 21 Common Transitions. Links from Transition to Step have been reduced, but there are still many links from Transition to Step.

With the current workflow, most of the new Common Transition are not in the Nominal Scenario : Cancel, Reject , Request more Info, Enter Info, Edit, Put on Hold. Then, you are able to hide Links from Steps to Transition …

Workflow XL Light (Common Link hidden)

I hope you do not have to design workflow as complex as this one, but I imagine that you do not have time to invest in learning the XML syntax for OSWorkflow library.

Like the default Workflow Editor, with Minyaa Workflow Designer, you will be able to :

1. Clone a Workflow or Create a new one,
2. Create Normal Step and Step Transition
3. Configure all Transition with Condition
4. Validator and Post-functions

Still unable to associate a Screen to your transition!

But also, you will access more features provided by OSWorkflow and be able to :

1. Move Step Transition as Common Transition,
2. Move Common Transition as Global Transsition,
3. Move Global Transition as Common Transition,
4. Detach a Step from a Common Transition,
5. Qualify any Step, Common or Global Transition as Recursive Transition,
6. Link a Step directly to a any Step or Common Transition
7. Link a Step to itself and also create a Recursive Step Transition
8. Have unused Common Transition
9. Use some special Worflow function provided by Minyaa
10. See your workflow in a graphical interface (It is always more easy to present)
11. Also create a Snapshot of your Workflow for documentation …

Download a 30 day Trial for Minyaa now and discover Minyaa Workflow Designer.
You can now design the workflow needed by your business, and  do not let a workflow design your business !

Your feedback is welcome to enhance the Minyaa Workflow Designer capacities.

Useful links to the documentation:

• OSWorkflow by OpenSynphony
• Minyaa Workflow Designer
• Transitions by OSWorkflow
  • Step Transition
  • Common Transitions
  • Global Transitions
  • Recursive Transition
• Post-Function
  • Back to Previous Step

Note : The re-factorization presented above was done using Minyaa 2.1

Minyaa is compatible from JIRA 3.13.0 to JIRA 4.1.2 (8 distinct builds).
News since Minyaa Suite 2.0 …

Release Notes :

• Minyaa is now JIRA 4.1.2 compatible,
• Minyaa Workflow Designer features have been enhanced (See details here) :
  • Re-attach a Transition to another Destination Step,
  • Re-attach a Transition to another Originating Step as Recursive Transition,
  • Qualify Step Transition as Common Transition,
  • Qualify Step or Common Transition as Global Transition,
  • Qualify a Global Transition as Common Transition,
  • Create Recursive Transition from a Step,
  • Setup Create and Edit Transitions mapped with Create and Edit Operations (Extended Issue Validation)

  See how to create a Workflow with Minyaa Workflow Designer ...
  

• New Workflow Functions (See details here) :
  • Post-function restoring the Issue to the step previous to the transition,
  • Validator on count of Selected Fix Version or Affected Version,
  • Validator for Fibonacci numbers (depending on Resolutions),
• New Custom Permission to allow or forbid to enter Worklog for past date (See details here).
• and some different bugs fixing … See detailed Release Notes

Download your Trial for Minyaa Suite now …

or ask for your Minyaa Starter License

In the coming weeks, I will publish a series of blog posts to give you more detail on each of our partners. I started this series with a first partner, the firm Northwest Cadence.

Northwest Cadence is an American consulting firm located in Kirkland, Washington.  They consult, coach, and train organizations to help them perfect their software development processes. They orchestrate the cadence between technology and teamwork to ensure organizations get triumphant results. Through a focus on team capability, Application Lifecycle Management, and optimal tooling such as Urban Turtle, Northwest Cadence is here to make you a winner and keep you smiling.

Steven Borg, founder of Northwest Cadence explains why they appreciate Urban Turtle:

“Urban Turtle dramatically reduces the tool friction involved in adopting agile with Team Foundation Server.  By clearly removing a significant agile adoption blocker, Urban Turtle helps teams ‘get’ agile more quickly and adopt more successfully.  I’m currently recommending Urban Turtle to all our clients adopting agile.  It eases the transition and teams love it.”

You can find an engaging compilation of Technical Tips, Knowledge Expansion, ASK SME, and Event Highlights by subscribing to their monthly e-newsletter. Do not hesitate to consult their website or read their blog.

Tweet This Post

Prise sur l’autoroute de la livraison, à la poursuite d’un modèle de processus qui venait de sortir. La tortue est désormais recherchée. Elle risque des années de travaux d’intérêts généraux, notamment dans le rôle d’accélératrice de solution pour les projets Scrum avec Team Foundation Server.

Source : Urban Turtle delivers a kick-ass experience for Scrum in Visual Studio Team Foundation Server

Pour télécharger la version compatible avec le tout chaud modèle de processus Microsoft Visual Studio Scrum : Urban Turtle

One of the main orientations is to build Urban Turtle into TFS (as opposed to integrate with). All our design decisions are made to bring as much value-added as possible while creating a seamless experience for existing TFS users and grow with TFS as Microsoft adds new features.

If you are interested about the details of the three releases we have made since the Visual Studio 2010 launch in April, please read the following posts:

1. April 30th – Urban Turtle 3.0 RTM is now available!
2. June 4th – Urban Turtle 3.1 now available!
3. July 8th – Urban Turtle 3.2 now available! – Support Visual Studio Scrum 1.0

We believe this orientation is what allows us to have a product that installs on the server in less than two minutes and gets a team to use it right away. We are very interested in hearing your stories and get your feedback about how we can further improve the experience.

Help us make our Urban Turtle a Chameleon

Also, our tight integration in the Web Access user interface makes the user feel at home and perceive TFS with new capabilities (as opposed to using an extra product). This is a big plus to have a smooth user adoption. We know that adopting scrum is already an interesting challenge; you do not need tools to get in your way but be a possible accelerator.

Again, give Urban Turtle a try and let us know how we succeeded in turning it into a Chameleon.

Tweet This Post

Last week, I attended the breakfast conference presented in Montreal by Ken Schwaber.

As always, Ken gave a great presentation focusing on the “definition of done” in Scrum and the impact of incorrectly defining what done really means.

As I was listening to the presentation, I looked outside the window overseeing René-Levesque boulevard and noticed an asphalt truck and city workers filling a pothole – then it hit me… As interesting and valuable Ken’s presentation was, we need a systemic approach if we want Scrum to succeed in organizations. Let me explain…

Nobody likes to drive on a street with potholes. So what do cities do? Obviously, they fix them! If you live in Montreal, you realize that every year, the city fills thousands of potholes in an attempt to keep their streets in a good driving conditions but no matter how much efforts (and money) the city invests, the potholes keep appearing.

Isn’t this like implementing Scrum within an organization?

As attendees to Ken’s presentation, weren’t we simply like city workers attending an asphalt conference? It is as if an asphalt guru was explaining to us the right mix of tar and rocks to make the most resistant asphalt when in reality, the problem isn’t really with the asphalt itself but with the city’s traffic management approach.

Same goes for Scrum.

The definition of done is critical. The right people in the right roles is important. Dedicated teams members is crucial. But what about the managers in the organization? Are they supporting Scrum? I mean, are they really supporting the use of Scrum within their organization?

Don’t get me wrong. I truly believe doing Scrum the right way is critical but it is not sufficient to be successful. If your managers aren’t on board, you can try to implement as many of the Scrum best practices as you want – including the right definition of “done” – your teams will never reach the highest level of performance they could. Get the managers on board and your Scrum implementation will be greatly improved.

You might be interested in these related posts:

1. Agile Data Warehouse
2. Introduction to Scrum – Shareable Power Point Presentation
3. 4e Salon Business Intelligence in Montreal

The only thing of note is that I got late in my RSS feed (again) so I missed the announcement of Corey Haines’ Learn How to Type Week.

I repent and decided to try my own this week (along with a few colleagues).

I’ll keep you posted about the results. I’ll work in increasing my wpm.

I finally registered to attend the upcoming Agile conference in Orlando. Just like last year, I’ll be posting my thoughts on the various sessions I’ll be attending.

An invitation for my fellow bloggers or to people who are passionate about Agile Organizational Coaching. Drop me an email (mproulx [at] pyxis-tech [dot] com) if you would like to chat or meet for lunch.

I’ll be there with Eric and Jean-René, two great coaches.

You might be interested in these related posts:

1. Someone is looking for a job
2. Looking for a challenge? You may be interested in an Agile Organizational Coach Job
3. Interesting blog posts (February 1, 2010)

This morning I sat down with François to prepare the first hiring interview of a candidate looking for a software developer position. We decided to not have a look at his resume just yet. Since one of our colleague had recommended the applicant, we trusted he was a good candidate and wanted to understand if there was a cultural fit.

We talked about the values, characteristics and behavioral traits we wanted to find in a potential colleague. We figured out we wanted someone who shared the following characteristics:

• Accountable
• Humble
• Passionate
• Intelligent
• Team-oriented
• Continuous improvement orientated

We then devised a series of powerful questions to help us figure out if the applicant was someone we wanted to work with. Below are some of the questions we used during the interview process. Keep in mind that those questions are no more than tools we used to orchestrate the conversation. How we frame the questions is decisive. To make sure we hire right, the questions have to be ambiguous, personal, and stressful:

• Tell me why it is more important for you to be having this conversation with us, rather than being doing something else?
• What are the things you hear yourself most often complain about in your current (or last) position?
• What have you done to change the very things you complain about?
• What would be an extraordinary accomplishment for you?
• What is the greatest contribution that you plan to make to the organization?
• What will you hold the organization accountable for?

With answers from the candidate to questions such as these, we now have a pretty good idea whether the candidate is a good fit for our organization or not.

The next step is to validate the technical skills of the candidate. I know of no other way to validate the skills of a developer than to orchestrate a conversation around code. So we will give the candidate an opportunity to show us what kind of developer he is through his code. But that’s another story.

A not so far-fetched example

Let’s just imagine that we walk into DoMoreTech Inc. and we are confronted with 40 developers, 4 QAs, a few ivory tower architects and control hungry project managers. Not to mention a management team that believes taylorism is still the best way to create software.

The Java developers are totally separated from the back-end C developers. A test means starting up the Tomcat server and clicking away.  If you mention unit or automated tests, they look at you like a bunch of deers caught in the headlights. For the past 20 years or so, C developers have been masters of their domain and are very comfortable working within the three and half carpeted walls of their cubicles.  One of them even installed a makeshift cardboard roof to cut down on noise! Oh, yes! And everyone is working on at least 5 projects in parallel.

The QAs are on a mission: Embarrassing the developers during the weekly “team” meeting. To ensure that they reach their bug finding quotas, they withhold information that might help developers today.

Developers tremble when he appears at the elevator doors. Even the paying client with clearly define business needs folds under the pressure of the all mighty Architect.  The Architect has positioned BDUF as a critical process that must be respected for any and all projects to be successful. This well defined process is flawless and the Architect’s design is always perfect and final. If there’s a problem, it’s obviously due to the developer’s lack of maturity and experience.

Project managers and management are really happy that this “Agile thing” will help them do more with less. Since they are not part of the problem, only the technical teams need to improve the way they work.  Now that they have “purchased” Scrum, they have ADDITIONAL tracking tools to better control the situation and make better decisions for the teams.

Ok. Now what?

After a few days, when all these non-winning conditions are confirmed – What do you do as an Agile Coach? Jump in and hope for the best? Run away and never look back? Or maybe do away with the detailed diagnostic and simply leave a Hallmark card on the manager’s desk saying: “Sorry, but this ain’t gonna work”

Personally, I’ve seen watered down variations of the example above in different organizations and I’ve never turned down a client.  But to even hope for agile transition to succeed, the client does need to comply with two simple requirements:

Requirement 1

A pilot project (unless “Big Bang” implementation is considered). Neither a small and meaningless “test tube” project nor a do or die project. How about something just in the middle that involves external dependencies and creates value?

Requirement 2

We need a team. To quote a colleague of ours: “We don’t coach projects, we coach teams!”  And this team needs to be committed to one project. This Scrum team will be composed of a ScrumMaster, Product Owner and qualified individuals to create the solution.

Whether or not these requirements are met, a Mandate Charter is created in collaboration with the client to clearly define, among other things, the conditions of success (COS) of our initiative.  Taking time with the client to establish the conditions of success is a great collaborative activity and allows us to have those hard conversations and setting some facts straight.

If the basic requirements are met, the COS can be far reaching and beautiful things can happen!  If not, the COS might be superficial or even cosmetic in nature.  At this point, decisions need to be made.  Is the client willing to pay for cosmetic changes to his or her organization?  Does the client see value in these changes and is he or she able to sell ME on it?

It’s all about managing expectations.  A client can’t expect an agile coach to turn water in wine. But allow a coach to work with some quality basic ingredients and we just might end up with an award winning Cabernet Sauvignon.

Party on!

I am very aware of the previous debates on the need for an Agile Maturity Model (see the Other Useful Links at the end of this post). I actually agree with Esther Derby’s recent post …

How agile you are doesn’t matter. Whether you are 50 per cent agile, 90 per cent agile or agile through and through (what ever that means), doesn’t matter. What does matter is that your company is satisfying its customers, stakeholders, and employees. (Achieving Agility: Means to an End, or End in Itself)

But let’s face it, people like to know where they stand compared to others. Starting at a very young age, we have been raised and trained to compare our results to others in an attempt to reach the next level – whatever the next level may be.

We get into such comparison as:

• Are my grades better than Tommy’s?
• Can I run faster than Carl?
• Am I stronger than black belt Anna?
• Did I earn more frequent flyer miles than Frank?

It’s the same thing with Agile. People – managers and executives mostly – really have the need to know they are headed for the top of the maturity model. It may not make much sense but they have been raised and trained to measure, to compare, and to brag when comparing favorably or to adapt when comparison isn’t positive for them.

As I already stated, I agree with Esther when she says that it doesn’t really matter how Agile you are. What matters are the results. So along those lines, I believe it is important to associate the level of maturity and the related results which I believe exist and can be demonstrated.

Unfortunately, there isn’t much hard data to demonstrate that achieving a certain level of maturity provides x% of improved performance or y% cost reductions but most of us who have been implementing Agile within organizations would agree that that higher the maturity, the better the results. So it is based on these observations that I decided to present yet another Agile Maturity Model.

As recently reported by Forrester, Scrum being the most adopted Agile approach these days, the proposed maturity model heavily relies on the adoption of Scrum practices with a lesser consideration to other practices such as: Agile Modeling, Feature-driven development – FDD, Test-driven development – TDD, eXtreme Programming – XP, etc. By no mean I am rejecting or considering those other approaches non-important. I built this model mostly on Scrum because this is the comparison organizations are asking us to be evaluated on at this time.

The Agile Maturity Model

Level 1 – Team Level Maturity

At this level, team members have decided to adopt Scrum and/or software engineering practices without asking for approval from their manager. Some of the well known practices are used but without consistency.

Team

• A Scrum Master is in place
• The Team has adopted some of the Scrum practices and artifacts but may not use them consistently
• The process isn’t documented and tends to vary by project
• Agile practices have been self-taught
• Process is limited to the solution team
• The team doesn’t understanding the language used by the business representatives

Department

• Outside the team, almost nobody has heard or understand what Agile means
• Other teams are unaware or not interested in the approach used by the Agile team
• Mostly business as usual

Business

• Unaware or not interested in the approach used by the team
• Business as usual
• Complains that what the information technologies team delivers is not what is needed or asked for
• Misunderstanding of the language used for the development team

Project Managers

• Unaware or not interested in the approach used by the team
• Follow the traditional project management approach

Managers

• Unaware or not interested in the approach used by the team
• Business as usual

Results

• Team is slightly more productive
• Moral is slightly improved
• Much friction with project managers, people managers and the business as the team members try to teach people outside the team what Agile is and what it can do for them

Level 2 – Department Level Maturity

At this level, the practices adopted by the team members have started to be imitated by other teams within the software development department. Some of the managers have noticed the positive results of adopting the Agile approach and are tempted to replicate what they observed.

Team

• A Scrum Master is in place
• Some of the teams have adopted some of the Scrum practices and artifacts and are starting to use them consistently
• Consistency across the teams is uneven and mostly depends on the leadership and perseverance of a few individuals
• Some of the process is documented but it tends to vary by team
• Agile practices have been self-taught or a coach was hired to help the team launch their initiative
• Process is limited to the department

Department

• Mostly business as usual
• Agile is sometime discussed in departmental meetings with some interest from people outside the team immediately impacted
• An increasing number of teams are adopting Agile practices

Business

• A business analyst acts as the proxy for the business representative
• Unaware or not interested in the approach used by the team
• Collaboration between the development team and the business side remains mostly unchanged except maybe for increased interaction between the 2 groups
• Business decision are still mostly made by business analysts or architects

Project Managers

• Starting to be aware of the new practices used by some of the teams
• Mostly resistant to change since they are lacking information about the new process
• Follow the traditional project management approach
• Do not consider the Agile approach to be very solid for large scale projects

Managers

• Unaware or not interested in the approach used by the team
• Business as usual

Results

• Teams that have adopted the Agile approach are slightly more productive
• Moral is improving
• Productivity varies from one team to the next
• Some teams’ productivity is decreasing since they have hit important hurdles
• Some teams have abandoned the new approach and have gone back to their traditional approach
• Some friction between the development and the business teams in light of the new approach

Level 3 – Business Level Maturity

At this level, the solution teams have integrated the business people in the model. Collaboration (and trust) has increased and a partnership relationship is increasing.

Team

• Scrum Masters are in place
• The 3 Scrum roles are well understood and respected
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• External help has been used to achieve this level of maturity
• Team members are attending Agile conferences

Department

• There is confusion around the roles of: business analyst, architect, database administrators and project managers
• The process is documented and tends to be consistent across projects
• External help has been used to properly implement the Agile practices

Business

• A Product Owner is clearly identified and may be dedicated to their project
• The concept of incremental and iterative development is gaining more acceptance from the business representatives
• Process is slowly expanding within the business side
• Product Owners bring some of their colleagues to end-of-sprint demonstrations

Project Managers

• Starting to be aware of the new practices used by some of the teams
• Mostly resistant to change since they are lacking information about the new process
• Follow the traditional project management approach
• Do not consider the Agile approach to be very solid for large scale projects

Managers

• Awareness is increasing at the director level within IT and Business of the new Agile approach
• Many assumptions and misunderstanding remain
• A strong evangelist is in place to promote the new approach and bring together the IT and business side of the organization

Results

• Project teams using the Agile approach are more productive
• Moral of the people using Agile is much higher than those outside the Agile teams
• Some friction with project managers and people managers remain where most people tend to fall back to their traditional paradigms

Level 4 – Project Management Level Maturity

At this level, the project management approach is modified to include some of the Scrum practices. Although the department still mostly relies on the traditional PMBOK recommendations, Scrum has been integrated in the project management approach.

Team

• There is a clear segmentation between the role of the Scrum Master and that of the project manager
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• Interference with the team’s activities is almost eliminated
• The team is autonomous and the Scrum rituals and artifacts are respected and standardized

Department

• The department has adopted many of the Scrum practices and artifacts and are using them consistently
• Much of the confusion around the roles of: business analyst, architect, database administrators and project managers have been eliminated
• The process is documented and is consistent across projects
• External help has been used to properly implement the Agile practices

Business

• Product Owners are clearly identified and are dedicated to their project
• The project manager is well accepted and is part of the Product Owner team
• The concept of incremental and iterative development is fully accepted from the business representatives
• Process is expanding to the business side

Project Managers

• Projects managers are fully aware of the new practices used by the teams
• Resistance to change has been replaced with adaptation of the traditional approach to include a more Agile approach
• Agile is accepted as a solid approach for large scale projects

Managers

• Awareness of the new Agile approach is increasing at director level and above within the IT, Business, and Project Management organizations
• Some assumptions and misunderstanding remain for managers
• Training initiatives have begun for management and attendance is high
• A strong evangelist is in place at the management / executive level to promote the new approach

Results

• Project teams using the Agile approach are more productive
• Moral of the people using Agile is much higher than those outside the Agile teams
• Friction between traditional roles are being handled

Level 5 – Management Level Maturity

At this level, managers have adapted their management style to support an Agile organization. Organizational structures and reporting mechanisms are better adapted for collaboration and improved for increased performance.

Team

• Scrum Masters are in place
• The 3 Scrum roles are well understood and respected
• If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
• External help has been used to achieve this level of maturity
• Team members are attending Agile conferences

Department

• The department has adopted many of the Scrum practices and artifacts and are using them consistently
• There is no confusion around the various roles surrounding the projects
• The process is documented and is consistent across projects

Business

• Product Owners are clearly identified and are dedicated to their project
• The project manager is well accepted and is part of the Product Owner team
• The concept of incremental and iterative development is fully accepted from the business representatives
• Process is expanding to the management level of the organization

Project Managers

• Projects managers are fully aware of the new practices used by the teams
• The traditional project management approach has been adapted to include a more Agile approach
• Agile is accepted as a solid approach for large scale projects
• Review the best practices to adapt to changing realities

Managers

• Have fully transferred the authority and responsibility to the teams to allow them to do their job properly
• Avoid interference and micromanagement
• Promote collaboration and teamwork
• Support continuous learning and do not systematically penalize failures
• Adapt their management style to the context of their team

Results

• The various projects using Scrum are more productive than those using a traditional approach
• Moral is high all around
• Friction around the new approach has disappeared
• Strong collaboration between all parties involved
• Organization is able to quickly react to changes in its environment
• Management is considering implementing Agile to projects that do not require software development

Level 6 – Corporate-wide Level Maturity

Utopia or the nirvana? At this level, the entire organization – the people, the processes and the tools are aligned with the Agile principles and values. As I haven’t had the opportunity to witness such an organization (yet), I am unable to describe the criteria to be used to qualify for this level.

Other useful Links

• The Agile Maturity Model (AMM) posted on April 1, 2010.
• Does Agile Need Its Own Process Maturity Model? posted on June 1, 2009.
• Scott Ambler Revisits Agile Process Maturity Models posted on April 27, 2009.
• Agile CMMI: Complimentary or Oxymoronic? posted on December 19, 2008.
• The Agile Maturity Model posted on August 2, 2008.
• Does the Agile Community Need a Maturity Model? posted on October 16, 2007.
• An “Agile Maturity Model? posted on June 7, 2006.

You might be interested in these related posts:

1. Gartner’s “The Current State of Agile Method Adoption”
2. Agile Transition – What about the teams outside the transition?
3. Secret Revealed! Guaranteed Success for your Agile Transition

That’s why when I was challenged at work to take a few hours each week to train, I thought “What a great opportunity!”.

Well that’s what I should have thought. Instead I said: “But what about the project? The deadline? The world is going to end!”

Then I realized how lucky I was to work at Pyxis. I asked the Product Owner and it wasn’t such a big issue.

Lesson #1: Ask and thou shall receive

For my first training session, I decided to do the some katas in ruby as it has become my language of choice for pet projects.

Part 1 – Primes

I started my first session with the Prime Number kata. I like this kata since it is really simple, can easily be done in less than 30 minutes (closer to 10 once you’ve done it a few times) and I learned a few useful tricks in ruby by watching this kata permormed by Uncle Bob on Katacast.

I plan on doing the Prime Number kata every week as a warm up.

Part 2 – Bloom filters

Afterwards I tried kata #5 from http://codekata.pragprog.com/2007/01/kata_five_bloom.html – implementing a Bloom Filter. It’s an algorithm that probabilistically determine if an element is part of a set. It works like this : if the element is in the set, it will always return true. However if the element is not in the set, the bloom filter might still return true depending on some probabilistic stuff.

Training ends

Here are my highlights of the session:

• I learned a new algorithm, it’s purpose and a few use cases
• I performed everything in pure TDD
• Continued to learn new keyboard shortcuts in Rubymine (I try never to use the mouse in katas. If there is a keyboard shortcut I forgot, I look it up and make a point on using it)
• I managed to take some time to train!

The only downside I can think about is that I spent a little while trying to configure ruby 1.9.2, rspec and the latest beta of Rubymine 2.5 before reverting to ruby 1.8.7.

As for improvements, I see lots of ways to improve the Bloom Filter katas, especially when it comes to my tests. I’ll give it another try next time.

Support for Visual Studio Scrum 1.0
Urban Turtle 3.2 fully supports the new Scrum template from Microsoft from the get-go. This post introduces the new features that have been developed for the template, but I strongly recommend that you take some time to read this previous entry to understand the reasoning behind them. Most of these features can be configured to work with other process templates.

New Feature: Approval
Product Owners can now approve PBIs with a single click when looking at their backlog in the Planning Board.

New Feature: Commitment
We made it possible to commit to PBIs contained in a sprint with a single click, again from the Planning Board.

New Feature: Sprint Details
We’ve made it easy to create and access the Sprint work item through the Sprint Details button in the planning board’s iteration list.

New Feature: Favorite iterations and areas
As Dom mentionned before, we have been looking at ways to reduce the number of iterations and areas visible at any time. We’ve come up with a great idea which actually is not our idea at all. I mean, favorites is anything but new in software! Basically, you can now easily switch between viewing all iterations/areas where you can flag some of them as favorites, and then hop back to a view where only favorite iterations/areas are displayed. This effectively reduces the number of work items displayed at once and helps you focus on the task at hand.

Once again, we recommend that everyone upgrades to this latest version and we are eagerly awaiting your feedback. Let us know what you think in our community-powered support site!

Tweet This Post

I already talked about silence as a communication tool but I can now estimate the value of silence at nearly $600,000 per hour. I recently came to this surprising conclusion when I bought my new car a few weeks ago.

Before I tell you my surprising story, I need to explain a few things about silence. During my coaching development program, we were explained that leaving room for silence allows the other person to clearly express their thoughts and feelings. Without silence, those thoughts and feelings would be unspoken and hence, unknown.

Keeping silence in a conversation also puts an uncomfortable pressure on the person spoken to – to speak. Try it for yourself and see how strange the situation becomes when no one is speaking.

To help us as coaches, we were told to keep our mouth shut and mind focused by counting in our head. You leave room for silence and start counting (in your head, otherwise there is no silence!). 1, 2, 3, 4… While you are counting, the other person feels some pressure and most probably will start talking – usually what follows the silence is very useful information.

So back to my story.

After seeing a few dealers and selecting the car I was going to buy, I entered into the typical negotiation scheme with the car salesman.

• Salesman: “$xx,xxx. This is my final price”
• Me: “Sorry, that’s too high. I did research on the Internet and I have a pretty good idea what the markup is on this car”
• Salesman, looking shocked: “Let me see what my supervisor can do for you”
• Salesman, coming back after a few minutes: “It’s your lucky day, my supervisor says that he wants us to reach our quota, so we’ll take out another $1,500″
• Me: “That’s nice but it’s still higher than what I’m willing to pay for this car”
• (…) a few more rounds of negotiation (…)
• Salesman, somewhat surprised: “You know, (blah, blah, blah)…”
• Me: “I understand. Listen, thank you for your time. I’m not in a hurry so I’ll keep shopping”
• Salesman, getting anoid: “Listen, if you are that serious. I’ll take out another $1,000 but that’s really the best I can do!”
• Me, pulling out my credit card to make a deposit: “I don’t believe this is the best price you can make. What else can you do…”
• SILENCE
• Me (counting in my head): “1, 2, 3, 4, 5, 6…“
• Salesman: “I’ll take out another $1,000 but I can’t and won’t go down anymore”
• Me: “Deal!”

$1,000 off the final price for 6 seconds of silence. Isn’t that a nice hourly rate!

You might be interested in these related posts:

1. Using silence as a communication tool
2. The new employee has an opinion
3. It's Sunday and I can't wait to go to work tomorrow

As Agile Coaches, we aim to be efficient. We analyze the situation around us, we ask questions, we experiment, we share our thoughts and observations, we make suggestions and recommendations. We try to be helpful.

Are we always efficient in the way we ask our questions? Could we ask our questions differently for better impact?

Below is a list of qualities associated with Powerful Questions taken from the reading material of the certification program I’m currently undertaking.

• Clarity
• Brevity
• Relevance
• Direct
• Single Subject
• Positive expression
• Allow silence for the response

To be powerful, the questions should also have an impact. To be impactful, the question should aim at:

• Personal issues and remain contextual;
• Motivation behind the actions;
• Consequences of the actions.

And include the question “what else?”.

What we are looking for in the levels of information provided is:

• Facts
• Emotions
• Opinions

Finally, to be truly powerful, the questions should take the person out of his comfort zone in order to explore new horizons. Questions such as the following are usually very helpful:

• What would happen if …?
• With hindsight, what can you see?
• If you were an expert in this field, what would you do?
• If you had a magic wand, what would you do?

Formulating a question isn’t always easy but to be an impactful coach, properly asking the question is critical. Hopefully, these few tips can help you become a better coach.

You might be interested in these related posts:

1. What Is Coaching? And Other Relevant Questions
2. It's Sunday and I can't wait to go to work tomorrow
3. On my way to coaching certification

I remember when I started using JUnit. It was summer 2000, and I became addicted to writing tests first. I was already writing automated tests at that time, inspired by my lecture of Thinking In Java. Not using any automated unit test framework, I was writing my tests last in the good old main() function. I had to inspect the outcome of my tests for correctness each time I run them, and that was painful.

JUnit was a discovery that changed the way I programmed and approached software development forever. Central to xUnit frameworks is the notion of making the tests self-checking by using assertion methods, basically utility methods that evaluate whether an expected outcome has been achieved. Now I had a way to express the expected outcome, let the computer check it for me, and produce a useful message for me (and others) - the human readers - to help diagnose problems. One of the goals of automating tests is to use tests as documentation. In case of test failure, what you want is for the test to act as a tracer bullet, helping you understand very quickly what the problem is. Assertion messages play a role in this. A well-crafted assertion message makes it clear which assertion fails and what the symptoms of the problem are. Now that’s easy to say, the hard part is to figure out what the message should say.

As Nat Pryce and Steve Freeman explain in their book, during the test-driven cycle, after you make the test fail, take a moment to read the assertion message, ask yourself what the reader will get out of it, and adjust to make the diagnostics clear. They provide a number of best practices in the book to help with test diagnostics. One is about making the assertion messages explanatory.

I have long been in the school of thought that strives to have a single assertion per test method and as result, for a long time I felt no need to use assertion messages. If you use small and focused tests and name them well, the tests will tell you most of what you need to know to diagnose the problem. For example, when the following test fails:

calculatesGrandTotal() {
    String[] prices = { "50", "75.50", "12.75" };
    BigDecimal expectedTotal = new BigDecimal("138.25");

    for (String price : prices) {
        cart.add(anItem().priced(price).build());
    }
    assertThat(cart.getGrandTotal(), equalTo(expectedTotal));
}

the failure report can be considered enough to understand what the problem is:

Expected: <138.25>
     but: was <139.25>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
	at test.com.pyxis.petstore.domain.order.CartTest.calculatesGrandTotal(CartTest.java:53)
	...

Indeed, the name of the test tells us that the cart fails to calculate its grand total correctly. The assertion messages shows the difference between the expected and actual outcome. Yet we can make the diagnostics even easier for the reader by simply adding an assertion message to identify the value being asserted:

    assertThat("grand total", cart.getGrandTotal(), equalTo(expectedTotal));

See how that helps:

grand total 
Expected: <138.25>
     but: was <139.25>

I’ve come to adopt that practice since reading Pryce and Freeman’s book. Assertion messages are not used as often as they should. They can really help make failure reports more helpful, whether you have a single or multiple assertions in your test.

Another help in making assertion reports clearer comes from using Hamcrest matchers and assertThat(). Consider the following example:

findsItemsByNumber() throws Exception {
    havingPersisted(product);
    havingPersisted(anItem().of(product).withNumber("12345678"));

    Item found = itemInventory.find(new ItemNumber("12345678"));
    assertThat("available inventory", found, itemWithNumber("12345678"));
}

In case of failure, here is what we get:

java.lang.AssertionError: available inventory
Expected: an item with number "12345678"
     but: number was "87654321"
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
	at test.integration.com.pyxis.petstore.persistence.PersistentItemInventoryTest.findsItemsByNumber(PersistentItemInventoryTest.java:56)

which I hope make the point.

As Pryce and Freeman say, diagnostics are a first-class feature. I now do my best to make assertion messages helpful so that whoever has to change the code in the future will understand what the expected behavior is.

A few weeks ago, I wrote about The Nine Dimensions of Agile Leadership. As a follow up to that post, I came up with a preliminary Agile Leadership Assessment Questionnaire. Without being scientific and statistically representative, this assessment highlights the strengths (and weaknesses) of the leadership supporting the agile initiatives.

Simply download the questionnaire and select your answers (column D) to each question. The second tab of the spreadsheet presents a graphical representation of the results (as shown below).

You can download and try the Agile Leadership Assessment Questionnaire for your projects. This work is licensed under a Creative Commons Attribution-Noncommercial 2.5 Canada License.

Share your thoughts with me on this tool.

You might be interested in these related posts:

1. Results of my 360 degrees feedback. What my colleagues had to say.
2. Using a 360-degree feedback form to assess your leadership
3. Scrum Artifact: Burn Down Chart

• Where do we put the time for meetings?
• Do we need to have absolutely all tasks in the sprint backlog?
• When we are pairing, do we do time entries for each of us?
• When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals)