Tag Archives: project management

Good Project Management Practices

I find myself working as a project manager, or a program management consultant more frequently in the last few years. As would be expected by those reading the Curious Cat Management Improvement blog, my project management views are based on the management improvement principles I have discussed here for over 20 years.

This post is in the style of my Good Process Improvement Practices and Practical Ways to Respect People posts.

Good project management practices include

Deliver a working solution quickly; add value as you have time. Don’t aim to deliver a final product by the deadline and risk missing the deadline. Deliver a good solution early, adjust based on feedback and add more as you have time.
Prioritize – do fewer things, and do them well.
Limit work in process (WIP) – finish tasks, avoid the problems created by splitting attention across numerous tasks.
Consider the long term from the start – build solutions that allow iteration and continual improvement. An initially very good solution that is difficult to adapt as desires change is not a good solution.

image of the cover of Managmenet Matters by John Hunter

Management Matters: Building Enterprise Capability by John Hunter

Grow the capability of the organization while making progress on projects.
Use data wisely (data can be extremely valuable and should be used much more, but it must be used with a critical eye).
Use retrospectives during the project and at the end of the project to continually improve the process of managing the project (and the capability of the organization to manage projects overall).
Practice respect for people
Coach people on good management improvement practices as those opportunities present themselves as the project moves forward. This will let them be more effective on the project and also build the capability of the organization for the long term. Don’t just “trust” people to succeed without giving them the proper training, coaching and authority.
Select the right people for the project – the decision makers and those working on the project need to include those most knowledgeable about end users for the what the project will deliver. Those involved also need to have the right knowledge, personality, skill and roles in the organization.

Tips

Continue reading →

Magnetic White-Board Kanban Card Options

Just some quick ideas for Kanban whiteboard magnetic card options from a question I answered on Reddit.

Here is the best lean solution: Trying Out My Agile Kanban Board from Jon Miller.

kanban board with magnetic whiteboad cards

Magnetic kanban board from Jon Miller.

Why, well mainly I am kidding about it being the best, but if you don’t read his Gemba Panta Rei blog you should! Go add it to your RSS feed reader, before you continue with this post.

Ok, welcome back. In addition to thinking his blog is great the solution from his blog is very flexible and easy – though it isn’t quite a packaged solution (as asked for on Reddit). Also that post provides some good insight into the thinking behind the board (as well as how to create your own).

More links with kanban board options: Magnetic whiteboard cards (50-pack) – Physical Taskboards – I think just magnetic symbols (not magnetic white board card) but could use magnet with icon to stick paper to the board

Another silly site, that sells some sort of solution, blocked my access because they don’t sell in the country my computer reported being located in. So I didn’t give them a free plug (assuming their product was decent which it might be?). Very dumb design if you ask me; well even though you didn’t ask, I told you anyway.

Localization that impedes users rather than helping them seems far far too common in my experience. Mapping (and related – find closest…) uses are about the only localization stuff I find useful – country based localization I nearly always find annoying or crippling. And showing my location on a map is totally awesome (especially as I travel around as a tourist – or really in whatever capacity). Such bad design and poor usability decisions cost companies money.

Agile Story Point Estimation

In agile software development tasks are documented as user stories. Then the level of effort for those stores can be estimated by assigning each story points. The velocity that can be produced in a period (called a sprint, for us 2 weeks) can be estimated. Thus you can predict what can be delivered in the next sprint (which can help business managers make priority decisions).

I have found estimation to be worthwhile. In doing so, we accept there is a great amount of variation but points give a hint to scale. They can help prioritize (if you have 5 things you want but 1 is much harder you may well drop that to the bottom). I have always accepted a great amount of variation in the velocity, worry about the variation I don’t find worthwhile. I do think trying to act as though the velocity is precise can lead to problems. At the same time having a measure of velocity, even accepting understanding variation was present, was useful.

Over time reducing variation (probably largely through better estimation and perhaps a few better tools, reduced technical debt, better documentation, testing…) is helpful and laudable. We made improvement but still lots of variation existed. The biggest help in reducing the measured velocity was breaking down large stories to more manageable sizes. The challenge of estimating user stories, I suspect, has some fairly high variation (even with good system improvements that can help reduce variation).

Large stories just can hide huge variation in what is really required once getting into implementing it.

The way we did estimation (discussing in a sprint planning meeting) did take some time (but not a huge amount). It was agreed by those involved that the time spent was worthwhile. Sometimes we did slip and spend too much time on this, that was an area we had to pay attention to. The discussions were educational and helped provide guidance on how to approach the story. The value of discussions around estimations was probably the biggest surprise I have had in implementing any agile ideas. The value of those discussion was much higher than I imagined (I basically anticipated them just as non-value added time to get the result of an estimate, but they were a source of learning and consensus building).

These thoughts were prompted by: Story Points Considered Harmful – Or why the future of estimation is really in our past…

Continue reading →

Management Improvement Blog Carnival #156

The Curious Cat Management blog carnival highlights recent management blog posts 3 times each month. The posts generally focus on the areas I have focused on in the Curious Cat Management Guide since 1996 (Deming, evidence based management, lean manufacturing, agile software development, systems thinking…)

The Key Questions for a Minimum Viable Product Project by Anthony Panozzo – “What are you trying to learn with this particular MVP?
What data are you collecting about your experiment?
What determines the success or failure of the experiment?” [bold added – John]
Less Process, More Discipline by Charlie Martin – “Without it, you lose everything agile methods promise. The key to agile methods is this: You may have less process, but you must have more discipline.”

Sunset over Andaman, Khao Lak, Thailand. By John Hunter

Evaluating Executive Performance by Art Smalley – “One interesting thing that I will note that was considered in Toyota in Japan by the HR department when evaluating executives was how their previous departments fared after they had left. If the department continued to improve then this was generally a good sign.”
The evolution of design to amplify flow by John Hagel – “If we want to remain successful and reap the enormous rewards that can be generated from flows, we must continually seek to refine the designs of the systems that we spend time in to ensure that they are ever more effective in sustaining and amplifying flows.”

Continue reading →

Management Improvement Carnival #142

The Curious Cat management improvement blog carnival is published 3 times a month with hand picked recent management blog posts. I also collect management improvement articles through Curious Cat Management Articles, you can subscribe via RSS for new article additions.

5 Things a Good Product Manager Should Think About by Joseph Puopolo – “User experience has become such a core function to any product manager. Is this easy to use? Do people get pissed off when they have to use key features on the site? Will it cause people to abandon your site? UX can be a core competency and key differentiator. Always focus on this!”
21 Concrete Practices for Agile Managers by Jurgen Appelo – “1) Take part in a team’s stand-up meetings, and also answer the questions “What I did yesterday”, etc… 9) Keep every morning free of meetings, so you can do a gemba walk and solve problems… 18) Regularly have a look at a team’s output (the application that they are building).”
Why Create Poka-yokes—and Why Disconnect Them? by Michael BallÃ© – “Lines with overly complex Poka-Yoke devices tend to lose much productivity by having operators simply run the part through the detection device again until a part would be consistently stopped. Not surprisingly, production management can be tempted to simply disconnect the poka- yoke in order to run the line.”
10 Signs You Have a Bad Boss by Alison Green – “7) Ruling by fear. Managers who rule through rigid control, negativity, and a climate of anxiety and fear don’t trust that they can get things done any other way… 10) Fear of conflict. If your manager avoids conflict and tough conversations, chances are high that employees don’t hear much feedback and problems don’t get addressed.”
Should fixing bugs count toward velocity? by Jason Yip – “Velocity is a vector, not a scalar. So, should fixing bugs count toward velocity? No, we are measuring progress toward a goal, not effort expended.”
Interview with Akio Toyoda about Toyota Under Fire – Akio Toyoda on Jeff Liker’s new book, and Toyota: “you emphasize that you have to go back to the basics and this is the thing that I want them to learn the most. The business environment keeps changing. It is a dynamic environment, but as a company Toyoda was able to grow for the past 70 years or so and this is because there are some timeless values that we always have to keep true to. And that is the basics and that is what I would like them to learn.”

Continue reading →

Avoiding Tragedy of the Commons for Software Development

Kanban and Tragedy of the Commons

The “Tragedy of the Commons” archetype often manifests itself through “Shared Services”, when a small number of people with specific skills, work across different teams. Each team in isolation gets benefit from the Shared Service, but when demand for the service exceeds its capacity, then nobody benefits. At a smaller scale, a team with a low “bus factor”, or a hero, can also suffer from a tragedy of the commons, when too much work is dependent on a single person.

One of the comments on this post suggested that the tragedy of the commons wasn’t an accurate description. My comment:

I think the “tragedy of the commons” analogy works. As long as the users don’t have pay for use (or decide to prioritize) the danger exists for the abuse. So if you have a developer team and everyone just gets to dump tickets on to them and then whine if they don’t get what they want, when they want, I see the analogy as accurate. If people can just treat a resource as though it was suppose to just serve them and the resource is overwhelmed I see that as tragedy of the commons.

There are many ways to manage that problem (some manager deciding the priority for example). Then you may have other problems, but may avoid the tragedy of the commons scenario (in reality this setup is often done, but most don’t accept the prioritizations and just expect the development team to get everything done – which means you don’t avoid the tragedy of the commons problem).
Continue reading →

Assigning Story Points to Bug Fixes

Agile software development has teams estimate the effort to deliver requests from the product owner. The estimates are done in points (in order to abstract away from hours – as estimates have plenty of variation in how long they will really take). Then the teams capacity (velocity) is determined based on looking at how many points they complete in a “sprint” (a set length, often 2 weeks). Then the product owner can prioritize all of the requests with an understanding of how much effort each is estimated to take and the historical capacity of the development team.

I think it is good to add point estimates to bugs. It may well impact how bugs are prioritized – if it is known to be simple a program manager may say, yes I want these 6 first then… If then know the first 2 are likely to take a bunch of time, they may think, ok, I am not going to get these 4 for awhile… They might just accept that, or may wish to shift more hours to bug fixes this sprint. Or they might say well if it is that big an issue maybe we could do x instead…

In practice I rarely has us estimate emergent bugs we are going to fix in the current sprint, but we do it for bugs that are in the backlog. I sometimes will have us estimate a current bug if I think it is may take significant time – to help determine what we really want to and what the impact may be on the teams output for the sprint. We do not have many emergent significant bugs so it isn’t much of an issue for us.

We do have more difficulty accurately estimating bugs, compared to new stories, but we still provide actionable estimates (they are not perfect, but are usable).

We use agile software development principles at work and they have been a great help in letting us be much more effective than we had been previously. The discussion of priorities and delivery expectations are much improved by such methods I believe. And unrealistic expectations can be reduced. For various reason, without adopting some form of agile/lean… software development methods the common pattern I see is software developers being frustrated by unrealistic expectation of their customers (project managers…) being frustrated by failure to communicate what it is reasonable to expect and status updates. A big part of this is the failure to acknowledge variation (and the related difficulty in estimation). Agile/Kanban… are systems that take the variation into account, and therefore the variation is dealt with as natural instead of leading to bad outcomes for developers and their customers.

Response to Should story points be assigned to a bug fixing story.

Is Google Failing Too Often?

I think Google is extremely successful, but they do seem to consistently have problems adding to their portfolio. They did a great job with gmail. Android has been very successful. Google Maps is great. They did well building YouTube. Chrome is very nice. Automatic translation is very nice (as is the integration with Chrome).

But so many things just don’t go anywhere. I can’t understand why they can’t take something like Google checkout and make it much more successful (there is money even Google cares about waiting for success in this area). Grand Central was great – Google Voice has not built that the way I would hope. Google has an endless stream of very small companies they buy and then the service dies.

It has been long enough now that I am starting to feel more comfortable saying Google is not doing a good job of creating and building new products. There are a few successes. And having failures isn’t a huge deal – taking risks is wise. But they just seem to be succeeding far to little, especially when you look at the talent and resources they have. Of course, some will say the resources they have is a problem. I really think it is more along the lines I see you mentioning above – they have become too rigid in development. I actually support more standardization than maybe people want (there can be big benefits) but I believe you need to then allow for exceptions. It seems to me Google doesn’t allow enough. It is tempting for managers to want to duplicate the same style that has made adwords and search successful. That might not be the answer for every project though.

They also seem to be driving away to many people with a rigid adherence to proving every little thing. Now I think some of this is a significant part of Google’s success. The trick is not to throw out all such efforts, but to find ways to gain the benefits without crushing innovative people’s will to continue.

I continue to own stock in Google and believe the future is very promising. Google does far more right than they do wrong, but they have room to improve.

Jason Fried: Why work doesn’t happen at work

In this TED talk, Jason Fried, founder of 37 signals, discusses how people get work done. When asked where do you go when you really need to get something done, almost no-one says: the office (unless it is early in the morning or late at night)? This is especially for creative people and knowledge workers. They need long stretches of uninterrupted time to concentrate. “The real problems in the office are the managers and the meetings.”

The main theme is that interruptions can severely damage performance, especially for what Peter Drucker called knowledge workers.

He offers 3 suggestions to make the office a place people can get work done. No talk Thursdays. And if that is too much how starting with 1/2 a day Thursday once a month. Second, replace active distraction (meeting, going and talking to a person) with passive distraction (email and IM) that a person can turn off when they need to focus. I have found this very useful myself. And third, cancel meetings. He closes with: I hope I have given managers reasons “to think about about laying off a little bit and giving people some time to get work done.”

Management Improvement Internal Experts

Having a group of internal experts in Deming, lean thinking, six sigma, etc. can be an good way to help the organization transform but they must 1) practice respect for people and 2) focus on building organizational capacity. Having, for example a few experts that are very focused on lean thinking and can be tapped by others in the organization I think can be very useful.

That group might well also serve as “change agents” which can make some people get mad at them. They can help push the organization to change. While it might be nice to think you can just show the wonderfulness that is lean thinking and everyone will immediately drop all their old habits and embrace lean thinking that often doesn’t happen. You might well have to push middle mangers (and others) outside their comfort zone. And you might well have to push people to really try this stuff and they have become so disheartened over the years by promises of new, better, ways to work. They just see this as one more lame pointy haired boss attempt and they may well not want to play.

A big focus should be on making improvement in the performance of the organization, obviously, but also on making it clear that this new way of doing things is helpful and will make it a better place to work. The role of internal management improvements efforts is to build the capacity of the rest of the organization to improve. Six sigma efforts often instead put the emphasis on six sigma experts doing the improvement instead of coaching and providing assistance to those who best know the processes to improve, which I see as a mistake.

Response to The “Lean Group” Syndrome
Continue reading →