SystemsThinking.net

Lean games

First session of the day at XP Days France 2008: “Le système Lean“. Participants played in a simulation of a production line (similar to the one we use for the “I’m not a bottleneck! I’m a free man!” session) and gradually improved their results by by using Lean methods like Takt, pull, seeing waste, building quality in and learning.

I liked the way the game featured financial metrics to measure the cost and value of the “company”. Metrics and the learning could be useful additions to the Bottleneck simulation. Maybe we can add them for the Theory of Constraints session at the “Université du SI” in July in Paris.

Visibility for the non-participants wasn’t very good, due to the layout of the room. The audience of XP Days France has grown. Unfortunately, as you will see later, the rooms haven’t grown along.

XP Games

Meanwhile, Oli Lafontan ran the XP Game with 6 teams. That’s a bit much for one coach, so in the break Portia and I offered to help Oli coach. This was a good opportunity for me to see Oli at work and see the changes that he introduced to the XP Game. As usual at an XP Game, fun was had by all and everybody experience how an XP team collaborates, plans, estimates and reflects. See for yourself in the pictures.

May 09, 2008 04:42 PM

Marc Evers and I were a bit buzzed… We hoped, this year, to start announcing agile open earlier (and, unlike last year, not keep repeating ‘we should get started’). Well, unlike last year, we didn’t keep repeating it. We just didn’t get round tuit…

So last week, we finally got together around a whiteboard, decided that we did want to hold it in June (like last year, and as we planned), but we didn’t have a location etc. and didn’t want to spend as much time as last year in sending out invoices, dealing with exceptions etc.

So, we decided to go with an affordable conference location and leave things like hotel, dinner out of the basic package. That means we can send out just one type of invoice - you come two days, or you don’t, and  beside diet preferences there are no options. Well, you can of course volunteer (we got spontaneous offers for that. ) or sponsor.  We also decided to cap the conference at just thirty participants, so we could go with the venue. One of the reasons being, we thought we can’t get that many participants in a month anyway… Surprise, surprise, sending out the invite to a couple of mailinglists, and we’ve already passed the twenty participants mark. And we have some sponsors as well (we didn’t expect many in this timeframe, so we’re pleasantly surprised. Now we have to make sponsor packages and facilitate the other volunteers so we can self-organize )

So, without much further ado, I’m proud to announce the next

Agile Open Europe 2008

will take place in Utrecht, NL on June 5th and 6th. A vibrant place to push the envelope and do business together. And yes, we will find Belgian Beer - one participant listed that as a dietary requirement ;)  Looks like its’ going to be good fun again. See you there!

And if you ’still’ haven’t registered - there’s a handful of places left…

May 09, 2008 04:31 PM

I discovered two more great reviews of Manage It! Your Guide to Modern, Pragmatic Project Management. The first is a brief explanation of the Jolt awards. Take a look at Winners of the 18th Jolt Product Excellence Awards & Recipients of the Jolt Productivity Awards. (Scroll down a bit to see what Roland Racko said about Manage It!). One delightful quote:

Manage It by Johanna Rothman doesn’t have to say that because its encompassing wisdom and practical detailed hints speak with a clear voice giving a head slapping, obvious solution easily recognized as a practical fix for your current software management problem.

Martin White, who from his introduction, sounds like a project manager, posted a great review of Manage It! Some quotes I particularly liked:

It is when you get to Chapter Six that the author really starts to show her considerable expertise and her gift for communication. The chapter is entitled ‘Recognising and Avoiding Schedule Games’ and includes observations on various approaches to managing schedules, such as the ‘Bring Me a Rock’ game.

The chapter on managing meetings is quite superb, and starts with a section entitled ‘Cancel These Meetings’, highlighting that any meeting that does not clearly have a defined and measurable impact on the progress of the project should be cancelled.

Thank you Roland and Martin. You made my day today!

May 08, 2008 06:43 PM

Words convey meaning. They're how we take the stuff deep in our brains and share it with others. They also self reinforce. David Levy says I came across some new words reading Joe Little's blog entry Two Cheer's for the Nokia Test. In the post Joe says: "Why do I like it? I think it is a simple way to set some sort of lower boundary on Agile (Scrum) and it tends to make two problems more visible: Cowboy Agile on one side and Agilefall (aka Wagile) on the other side. Cowboy Agile is where you are doing stuff you are making up on the fly (mainly not doing things you personally don't want to do). Agilefall is where you are doing Waterfall (or mostly waterfall) and calling it Agile (or Scrum)." This started me thinking about some curious things I've noticed when looking at job descriptions for ScrumMasters?.

I suggest you can determine if someone is doing Wagile or Agilefall based on language. If you find command and control agile in the description, I propose you'll find an organization interested in Wagile/Agilefall. I offer the following examples.

From a job posting on Dice.com

Responsibilities

• Keeping the project on time, using Microsoft project.
• Setting team status meetings, track milestones, drive project.
• Being responsible for driving the team and managing them to hit the projects time lines.
• Leading scrum meetings
• There will be 4 - 6 people on a team

This was the first example I noticed. It's probably not the first one ever, but the mental models exposed grabbed my attention.

• Projects being kept on time using Microsoft Project?
• Drive the project?
• Driving the team to hit project time lines? (Does there seem to be a lot of driving going on?)

I was so amazed by this mashup of agile and command/control I didn't have the presence of mind to apply for the position.

Posted on the Scrum development email list

We are looking for a highly motivated Technical Project Manager eager to participate in the web2.0 world of user generated content, new media, hosted services and widgets. The successful candidate will be responsible for driving technical project management initiatives.

Responsibilities

• Be comfortable acting in a Scrum Master role to facilitate the development process and ensure timely delivery of work products across a variety of product teams.
• Identify and remove roadblocks for teams; shield teams from external interferences; work with the Product Owner(s) to maximize ROI; work with the Product and Development teams to ensure goals and backlog items are addressed.
• Help ensure that technical projects are delivered on time by managing the project schedule, mitigating risks as they arise and escalating issues as appropriate.
• Formulate and work to define technical scope and objectives of the project.
• Communicate project status to management and stakeholders.
• Work with development and product teams to define project schedule and iterative deliverables.
• Manage client expectations for projects to ensure ownership and success.
• Assist in the development of project budgets, capital expenditures, requirements or other cost estimates related to a project.
• Report to management, clients and others on the status of project deliverables and milestones.
• Responsible for combining successful software development process experience with agility, effective collaboration, facilitation, leadership and coaching skills.
• Responsible for advising and coaching the development team to form empowered teams.
• Manage project schedules in Microsoft Project and simple spreadsheets for backlogs.

Qualifications include:

• 3+ years Project Management experience
• Ability to work on multiple projects at once
• Proficient in Agile Development and strong experience with Scrum Methodology.
• Qualified candidates should have experience in all aspects of software development life cycles, with an emphasis on Agile methodologies.
• Scrum master certification a plus (Desired)
• Formal project management training and/or certification preferred.
• Fluency with Project Management Tools.
• Strong, attentive listening skills with ability to work in a fast-paced environment.
• Proficiency in Microsoft Project, Excel, PowerPoint?, Visio and Word required.
• Self-motivated, flexible and ability to multi-task and handle concurrent projects.
• Ability to influence and collaborate with all levels of technical and product business partners.
• Excellent interpersonal and communication (verbal and written) skills.
• The successful applicant will be a creative problem solver, a self motivator, posses a can do and attitude, positive mentoring skills and accomplishments, and demonstrate career building self improvement behaviors.

I considered not including the entire post (I did remove the company information) but felt to be fair I should include it all. Some parts of this don't sound too bad. For example:

• Responsible for advising and coaching the development team to form empowered teams. Sounds reasonably agile oriented.

But most of the responsibilities sound command and control not agile. And what's up with all this driving? "The successful candidate will be responsible for driving technical project management initiatives."

About this time I started to wonder if it was me. When I read the responsibilities, they make sense. These items need to be handled by someone somewhere at some time during the project. But the way the responsibilities are worded to me indicate a non-agile mind set in spite of:

• Responsible for advising and coaching the development team to form empowered teams.
• Proficient in Agile Development and strong experience with Scrum Methodology.

I'd like to say these two examples are unique in the recruiting business. Unfortunately they're not. You can find similar descriptions on just about any job board that caters to software development. I was going to quit with these examples, but I felt driven to find an example of cowboy agile. Alas, I didn't have to drive very far.

Also from the Scrum development email list

[Some company] is looking for a Certified Scrum Master-Project? Manager for a 2 month plus contract position for a client in [a city]. This project starts almost immediately and has a go-live date of June 1 [sic] with a project completion date of June 30. This would be our client's first time using Scrum so some training and mentoring of the team will be needed. At the end of the project, an evaluation of how Scrum could continue to be used as well as recommended in the next steps would be required.

There are about 10 people on the team. Other than training and mentoring, this person will be expected to be the project manager. They don't need to be a subject matter expert, just someone experienced in the Scrum methodologies of running a project. The training could just be a formal one-day training session at the beginning of the project and then just kind of on-going during the project.

Here the rules have changed. There are no rules. Am I the only person who wonders why a company with a time critical project (it goes live the day after scheduled completion) wants to shift to a new development method? And a lullaby word keeps being repeated.

• just someone experienced in the Scrum methodologies
• just be a formal one-day training session
• just kind of on-going during the project

If you didn't read Lullaby Language I recommend doing so now.

Crossed Goals

I decided to learn more. Maybe if I could talk with someone I could understand better what they were looking for, so I replied to one of the above. I received a nice email from the person which said they'd have to talk with the account manager and get back with me, which they did. The reply was no more illuminating than the original post. After a couple emails back and forth I gave up. It seemed the recruiting company needed a body to fill a slot regardless of how it would affect the client's outcome.

Truth in thinking:

1. It's hazardous to generalize from a single data point.
2. These are my perceptions. I could be wrong.
3. Just because something doesn't work for me, doesn't mean it won't work for someone else.

So, it is me? Or do others of you see agile being accepted as main stream verbage while the main stream continues to do business as always? Let me know. don (at) donaldegray (dot) com.

¹Tools For Critical Thinking, page 5

May 07, 2008 08:16 PM

I’m particular about two things: calling a prose plan a project plan and calling a Gantt chart (or yellow stickies) a schedule. One of my colleagues emailed me last week, explaining he’d spent a week developing a project plan and was hoping I could take a look at it. “Sure,” I said. “Send it along.”

He did. It was a Gantt chart for the next three months, with one- and two-week tasks. I called him and asked for a project plan, with release criteria. Did he have any? No. Had he checked with the people who were going to do the work to see if they could buy into the schedule? No, none of them were assigned yet. Dead silence on my end, trying to figure out how to ask the next question: Did he realize his schedule was already behind because 6 people were supposed to have already started?

I finally just asked the question, ignoring tact. He was quiet. I asked, “Why is this schedule so important to you?” “My manager wants the project done in three months.”

Managers can want anything they want. But wanting it doesn’t make it happen. This is where it’s critical to get started on working by chunk, so you can finish some work, and see where you’re going (I use velocity charts).

He challenged me, “What do you use for a schedule if you don’t make a Gantt chart?” I explained I kept a three-to-four week rolling wave schedule, using inch-pebbles.

If you’re given a deadline, you don’t need a long schedule. You need a short in-depth schedule, along with knowing what done means. You need to spend your time managing the project, not defining a schedule.

If you want to try some templates for a project plan, take a look at the Manage It! templates.

May 06, 2008 07:23 PM

I’ve written before about XP Days France. Time for an update.

The conference will be held on 5-6 May in Paris (not 12-13 May as announced previously). That’s only a few days away. Book now if you haven’t yet.

I’ll be there. I’ll co-host two sessions and attend fun, interesting and useful sessions.

Les neuf cases pour bien comprendre son client

This interactive session will be hosted by Bernard Vander Beken, Portia Tung and me. In the session, groups of 3 participants learn how to interview customers to help them to understand their problem and to write user stories. It’s a re-run of the successful session Bernard and I hosted at XP Days Benelux. Fun and learning guaranteed.

Real Options, l’ultime frontière

Portia Tung and I host this space game simulation to teach participants all about Real Options.

What are Real Options? They are a technique to make better decisions, by giving us more time to gather information and by considering more options. They are an underlying principle of Agile and Lean. This is an improved version of the presentation and game we ran at Agile North and at a tryout in London. At both events, players discovered some important lessons. They discovered that common sense is not so common, especially when we are under pressure.

A bientôt!

April 29, 2008 08:05 PM

Take a look at the Stickyminds review of Manage It! Jennifer says:

I highly recommend this book to all project managers, from novices to those with more experience. This is an incredible resource that should be referred to frequently for advice on how to help you decide which project management practice or technique is appropriate for your project–which she helps you to apply immediately.

Thank, Jennifer!

April 29, 2008 02:31 PM

I posted last month’s Pragmatic Manager email newsletter, How Many Emergency Projects Do You Have? I just sent out a newsletter on timeboxes and how they help multisite teams. You can sign up for my newsletter, and see the issues right away.

April 29, 2008 02:27 PM

Joe Little does a marvelous job recruiting speakers for the Agile-Carolinas meetings. This month was no exception. Israel Gat from BMC Software discussed "Leading the Disruption". This presentation focused on releases 2.3 and 2.4 of their distributed system management software. Near the presentation's end Brook's Law was mentioned and the question posed, "Does Brook's Law still apply?"

Why is it so?

Jerry (Gerald M.) Weinberg choose to use Brook's Law in Quality Software Management: Vol 1. Systems Thinking to demonstrate non-linear feedback systems. Combining Fig 5-1 (page 78) and Fig 6-4 (page 93) gives us:

I describe how to read Diagram of Effects here.

In essence adding manpower affects the system by:

1. Creating more communication paths. The number of communication paths is n*(n-1) where n equals the number of team members. This says increasing from 4 to 6 members increases communication paths from 12 to 30.
2. Adding new team members creates a training load on the existing team members. This in turn reduces the productive work finished.

These problems get exacerbated when managers decide to add "extra" manpower just to be sure the project doesn't slip any more.

Communications and Sharing Information

Tools to support software development methods have changed since Brook's Law was introduced. We now have information radiators for sharing information in parallel. By simply walking around your office it's possible to learn information about the project. Additionally wikis, build systems, source code management are types of information magnets. They hold pertinent information that can be searched, sorted and reviewed.

Staffing Considerations

There's a sliding window of opportunity where manpower can be added to a project and not negatively impact the schedule. This window closes when the additional productivity achieved by adding more staff isn't enough to offset the lost production due to training them. According to Israel Gat, BMC Software staffed the two releases with 80-95 developers compared to other companies who staffed similar sized projects with 25-35 developers. This staffing level resulted in product delivery in 4.5 - 5 months instead of over a year. This rapid delivery creates problems for the downstream organizational activities such as marketing, sales, revenue recognition and the back office. BMC Software recognizes this problem and is currently working on synchronizing the activities.

How to Beat Brook's Law

The state that invokes Brook's Law is "late". To beat Brook's Law all you have to do is avoid having late projects. What are some ways to avoid late projects?

• Staffing - BMC Software avoided late project delivery by aggressively staffing when they started the project.
• Cross functional teams - This keeps the project delivery from being derailed when something happens to a "key" developer.
• Incremental and iterative development - Customers rarely need all the new functionality at once. Delivering the highest value functions sooner relieves the pressure for a "big bang" delivery. The customer can decide to stop the project early if/when their needs get met.
• Fast feedback - This naturally flows from incremental and iterative development. Every two to four weeks the customer provides information on how well the development is doing at meeting the customer's needs.
• Continuous Improvement - At the end of each delivery cycle, set aside time to learn from the cycle's activities and events. What went well? What could be improved? Select something from the "What could be improved" list and work on it the next delivery cycle. Be sure to ask at the end, "Did we implement the improvement?" Some things take more than a single delivery cycle to get right.

April 29, 2008 01:46 PM

read more

April 28, 2008 09:40 AM