I'll be posting at the Modus Cooperandi blog on a regular basis, so you might like to add it to your RSS reader.

"You cobble them all [athletes and staff] together, give them a good environment, you push them, make them not scared to fail," said Brailsford.

 

"And you say 'Let's end up all over the track having tried to win rather than play safe and get a silver or bronze'. You remove that fear from the athletes and off we go."

Time and again, I find it difficult to find better management and leadership advice than Deming. I find that creating a failure tolerant, fear free, innovative culture is the key to creating continuous improvement and ultimately achieving world class performance. It's remarkable how well this advice holds up across so many walks of life: manufacturing; sports; and knowledge workers professions.

Currently, that means planning the forthcoming APLN Leadership Summit in Seattle.

I'm also going to be redesigning my blog and starting a fresh Channel APLN with a separate RSS feed. Look out for that soon.

I'm really happy with how the APLN is developing and the new focus we've brought to the organization this year. The APLN (note: we've more or less completely dropped the full name, Agile Project Leadership Network, in favor of a rebranding around the initials) knows what it wants to be now, a not-for-profit dedicated to bringing better leadership and management to knowledge worker industries with an initial focus on the IT sector and software development.

The APLN now has a clear focus around 3 main activities: Leadership Summits - these regional conferences provide learning opportunities for attendees and bring much needed funding to the APLN to support the other two activities; learning through a Wiki of Knowledge (LWOK) - if you like, a crowd-sourced alternative to other bodies of knowledge around project management; and a social networking and social media program designed to bring the community of leaders and managers closer together and provide transparency in to their achievements, learning, recognition and skills.

You'll be hearing a lot more about these APLN activities as the year unfolds. I'm proud to be part of the APLN and find the challenge of bootstrapping and developing a nascent, startup, non-profit organization, fun and engaging.

Related Posts: Digital Whiteboard Experiment, Return of the Sticky Buddy, Do you have your Sticky Buddy?

We've occupied the offices of Jim's old business Gray Hill Solutions on Seattle's Lake Union and we've opened up shop offering consulting on agile and lean enterprise transitions and training classes in Agile Management and Kanban. We intend to be leading the move to a more collaborative, higher trust, more open, more networked, more socially connected way of working in the 21st Century.

If you've been reading this blog for a while and wished, "if only we could hire David to come and help us..." or "I wish David taught classes in this stuff..." then your wishes have been granted. If you'd like to talk to me about helping you and your business be more successful, click the Hire David link on LHS navigation bar or drop me an email.

Please support the APLN by signing up for the conference and coming along to see Chris and I present in Dallas.

Purging the backlog is similar to a bug triage effort. You simply need some criteria to decide whether something stays in the backlog or is dropped. It could be very simple. For example, "anything over 6 months old is dropped." This simple rule fits with the real option theory nature of kanban pull prioritization. If something isn't important enough to get selected over a 6 month period, it probably isn't important enough - period!

Naturally, a more complex set of criteria is possible. You might want to assess the alignment with strategic, operational and tactical objectives of the business. You might want to assess alignment with particular customer segments or even specific customer orders. As we do, you might want to consider whether a change request is obviated with a forthcoming major release, or is requested on a system due to be decommissioned at some known point in the future.

Regardless, of your criteria, I'd recommend that you purge your backlog regularly, at least quarterly and perhaps monthly. Keeping the backlog healthy and relevant serves the business by simplifying prioritization discussions for kanban slots and by reducing queuing time and improving overall business agility from ideation to delivery of working software.

Related Posts: Kanban in Action, Recipe for Success Technorati tag: Agile, Lean, Kanban, Software+Engineering, Project+Management

This was all very well and given enough time and enough focus on Lean principles we might yet have evolved to a continuous integration approach for the enterprise but it would have taken years.

For the past six months I've been lucky enough to have Troy Magennis on my staff as our Enterprise Architect. Troy brought a wealth of experience in .Net and C# and large scale Microsoft technology projects to our team. Given that we suffer numerous impacts to our productivity with the constant challenge of code line management, integration, build and environment build out and reset, Troy refused to accept that continuous integration wasn't possible, and indeed in his view it was essential to eliminating waste and maintaining a regular flow of valuable software in to our production environments.

So together with one of our architecture team and a toolsmith from our configuration management group, they spent some considerable time and effort tackling the problem of how to build our entire enterprise code base in a continuous fashion. A few weeks ago, they finally achieved it and we now have cruise control reports on the state of our enterprise code base at any given time.

This doesn't mean that our enterprise DEV environment can be pushed to production whenever we choose. At least not without successful implementation of latent code and full regression testing to show that the new code is truly latent, but the result is that we have reduced our code line maintenance to a single line for all major projects in our portfolio plus a branch for sustaining engineering (released on a 2 week cycle).

At my prompting Troy has gathered his thoughts on Does Continuous Integration Scale to Enterprise Projects? what it takes to achieve enterprise scale continuous integration and how to implement it, in a white paper available over on his blog. You can get it in PDF here. The main takeaway from this article isn't a revelation about configuration management or build tools. The key to enterprise scale continuous integration is solid enterprise architecture and enforcement of good software engineering principles of loose coupling and high cohesion across all projects in the portfolio.

Yes, all you agilistas out there! Architecture does matter, if you are to scale agile techniques to the enterprise! Technorati tag: Agile, Software+Engineering, Enterprise+Architecture

Ideally, I'd like to run a side-by-side comparison over a 6 to 9 month period to compare these two options. How are you dealing with bugs in your kanban system? Like option 1 or option 2 or do you have you own alternative approach? Technorati tag: Agile, Lean, Kanban, Software+Engineering

You do. And I don’t buy that you’re actually managing them, or more than one of them. Sure, you might be doing damage control, or helping people see that they have a disaster. But you’re not evaluating and managing risk. You’re not checking in the team to know what done means. You’re not seeing if what you need from others across the organization will be ready when your project team needs it. Dare I say, you’re not managing. You’re busy.  (Way too busy multitasking.) You might even be providing help to the projects, but you’re not being proactive and you’re not there when the team needs you.

I don’t buy this business that a project manager can actually manage several simultaneous projects. Even if the projects are small. You PMs who are trying to do this: your managers are deluding themselves. Your call on whether to tell them. (Don’t tell them they’re nuts, that’s a career-limiting-conversation

For those of you who’ve met me and are wondering, “Where are Johanna’s glasses?” They’re in my lap. They were reflecting too much, so I took them off. Luckily I could see well enough to have a conversation with Deb.

They announced the awards with all the productivity awards on one slide, and we were supposed to stand up when our names were announced. They then do a drum roll and announce the Jolt winner for that category.

I saw Manage It! and my name on the slide and that was it. I jumped up right away, I was so excited. Maybe I’ll be more mature blase about this the next time I’m nominated for an award, but I bet not

I suggested he try baby steps. What’s the first thing the project needs to deliver? Just focus on one small thing. He did have an answer, but the feature was large. He thought it would take 2-3 weeks to deliver it, coded as well as tested.

Since he knew what the team needed to do, he could use timeboxes to focus people’s attention on that work. I suggested he use one-week timeboxes, to make sure people figured out what they needed to do, just for the first week, and that the project team work together to make sure they were all working towards the same goal. Once he got the first week working, he could do the same thing for the second and third weeks.

The reason one-week timeboxes work to focus people is that when a project is in chaos, people tend to be in chaos too. They get easily distracted. A timebox, especially a short timebox is really good for helping people make progress and breathe.

He had never done week-by-week planning, so I suggested yellow sticky scheduling, focusing on the deliverables that would finish the feature. It’s not a hard concept, so he was able to do it.

I caught up with him last week, and sure enough the timeboxes along with focusing on one feature at a time worked. He and the team were able to show progress, which bought them a slight decrease in pressure from the their senior management team. Now, he and the team could choose how to proceed.

I suggested he continue with the timeboxes and incremental approach to the project, to make sure people stayed focused and didn’t drift into chaos.

“But timeboxes seem like such baby steps. Do I really need to stick with the baby steps?”

No, he doesn’t have to. But there’s no reason to think that the people won’t go back into chaos as soon as they remove the focus of the timeboxes. And if he stops implementing by feature, they will revert to no progress.

I’m sure there are other solutions to the not making progress problem. But if an entire project is stuck, try small baby steps to bring some focus and progress back to the project.

Here’s what I like best about the book: it’s not theological. By this I mean Rothman doesn’t advocate one “true” way of running projects. She is very careful to be continually cognizant of context when she talks about different approaches you might take.

Dave also notes a bit about the schedule games in his review.

Potholes are a fact of life in the northern climates when you have cycles of freeze and thaw. But I’ve been talking to some folks whose defects are like potholes. “We only have time for emergency fixes.” “We have time to fix and fix the same darn thing over again, but we don’t have time to do it right.” That’s when your defects are like potholes.

Potholes slow down traffic, because the cars need to drive slowly through them, or around them. Defects, especially big ones, slow down other development or fixes. So, what do you do?

If you have a ton of defects, I would choose a one-week timebox, and work on fixing them. For me, fixing means developing a fix along with a unit test (or two or three), getting some peer review, and then checking it in so the developer can do some around-the-area testing before system test. I don’t care if the developers write the unit test first, I just care that they write some unit tests. Although, if you’ve got defects, you’ve got the makings of a bunch of great unit tests. I would not allow any development in this timebox, just fixing and checking the fixes in a variety of ways.

After making some progress and getting the defect counts lower, decide if you want another one-week timebox. Is it more valuable to finish (fix defects) than write new stuff and have old stuff unfinished? I don’t know, but you do for your project.

For the rest of the project, I would make sure people are working by feature, developing and fixing and checking a whole feature in totality before moving on to the next one.

If you’ve got a bazillion defects, they are like potholes–they prevent you from moving smoothly onto the next piece in your project. Fix them! No emergency repairs either–real fixes.

Yes, of course First, separate the team problems from the management problems. The managers get to triage the defects separately from the entire project team. Maybe a technical lead meets with them, but don’t involve the entire team.

Next, separate the work into one-week timeboxes, starting in the middle of the week. The project team has some idea about how many defects they can fix in a week, and how many features they can fix. Set up each week as a timebox, saying, “We’ll fix 38 defects and finish 3 features each week from now until the release date. We’ll decide on Tuesday afternoon which defects we’ll choose for the timebox starting Wednesday morning. If we have a show stopper problem, we’ll move that one to the top of the list and move whatever is lowest on the list out.” Notice what this timebox does: it makes it possible to see if people are working overtime on the weekend (a Bad Idea), it helps the team predict what done means for a specific time period, and it focuses people on the work to finish before the release. It also makes the managers rank the defects, so the project team works on the most important ones first.

Now, it’s time to address the status issue. With these inch-pebbles, it’s possible to have a 15-minute standup meeting every day. Note: If I was the PM, I would abolish the daily hour-long meetings anyway–the team gains no benefit from those meetings. If necessary, I would make a daily 2-minute appointment with each person. But a 15-minute standup meeting is even better. But if you, like my colleague, works in a place where people love their hour-long meetings, and never finish the meeting early, go to daily written status reports. (I have a template for status reports, too.)

Once the team has done this for a week, the PM can assess how close their time estimates are (how many defects they can fix and how many features they can finish in a week), as well as how many new defects are arriving each week. It might be time to “slow” down the defect fixing by adding reviews of the fixes, if the fixes aren’t actually being fixed. (I discussed this in my most recent Pragmatic Manager email newsletter. I haven’t posted that issue yet, but here’s one you might find useful, too.)

If everyone, including the project manager and the other managers are willing to be pragmatic, they have many options at the end of the project. But it’s clear to me it’s time to pull apart the problems and work on one at a time. Stop with the serial status meetings and let the project team get back to work!

Related posts: Lean NPD Summit Report

Eli Goldratt, the father of the Theory of Constraints, said: 'Tell me how you will measure me and I will tell you how I will behave.' Consider what would happen if workers were paid on the basis of their demonstrated skill-sets in specific knowledge areas, functional skills, and technological acumen, rather than their title and longevity within the organisation."

The jobs like painting will probably be completed sooner if you do them in parallel; paint a layer in one room, paint a layer in another room while the first room dries, etc. You're idle for less time, and the work is a fixed amount, so the math works in your favor.

in parallel (do a little of A, put it down, do a little of B, repeat).

This past week I focused on finishing chapters. I have about 16 chapters and one appendix. I don't know if the book will keep its current architecture; I removed one chapter yesterday. I have three chapters to finish (somewhere between 10,000-15,000 words) and three to rewrite (changing about 15,000 words? and a bunch of pictures). When I'm cranking, I can write close to 5000 words a day. Oh, and in case you're wondering, I'm writing in markup language, so I don't know how many of those words are markup and how many are content words. (This is similar to the problem of comments vs code when you count lines of code :-)

I've noticed these patterns in my writing over the last couple of months:

• When I know something cold, I use a form of mental shorthand. I write using that shorthand, losing my readers. I need reviewers to let me know I've lost them.
• When Daniel reviews my writing, he helps me refactor (yes, simplify) and I typically lose 10% of the words.
• I'm getting better at seeing when a piece is mis-organized, but I'm still not so hot at organizing it until I get feedback from someone.

So my next deadline is Jan 1, to finish this draft and have the book ready for tech review. It will be tight, but do-able.