Posts about project management

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 TaskboardsI 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.

Related: Visual Management with Brown M&MsMaking Data VisibleDeming and Software Development

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).

Related: Assigning Story Points to Bug FixesMistake Proofing the Deployment of Software CodeChecklists in Software Development

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

    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.

Related: Future Directions for Agile ManagementMistake Proofing Deployment of Software ApplicationsChecklists in Software Development

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.

Related: Why Google can’t build InstagramObservations of a New GooglerGreat Marissa Mayer Webcast on Google InnovationGoogle: Ten Golden RulesEric Schmidt on Management at Google
Continue reading

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.”

Related: Understanding How to Manage GeeksBetter MeetingsWorkers Allowed Recreational Use of the Internet are More ProductiveManagement By IT Crowd Bosses

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

Three Years of Real-World IT Projects In Ruby

Nice webcast by Martin Fowler, Three Years of Real-World Ruby. This talk is probably only of interest to those of you in software development, but for them I think it is an excellent presentation.

At work we have been use Ruby for the last 3 years and have found it to be a powerful language that helps make writing software applications fun. And that is important. By providing a powerful language and a rails framework that takes away much of the drudgery of writing code you can create an environment where develops are happy and productive. We are hiring, by the way.

The talk provides a good background on their experience using ruby to manage projects; and how they manage ruby application development projects.

Related: Combinatorial Testing for SoftwareChecklists in Software DevelopmentFuture Directions for Agile Management

What Managers can Learn From Open Source Project Management

What managers can learn from Open Source by Murray Cumming

Motivation: People work on open source projects because they enjoy it. These happy developers are productive developers. Managers of open source projects must ensure that the developers feel valued and fulfilled. They must minimise the tedious aspects of the work to ensure that development remains interesting. Otherwise, projects fail.

Although money can provide some incentive it does not provide as much. Managers who say that money is the greatest motivator are justifying their own poor performance. Managers of proprietary software, just like managers of open source software, must ensure that their developers are motivated properly. It is not enough to think that they should feel motivated.

Open source projects have the benefit of direct feedback from users. Systems such as bugzilla and open mailing lists make it easy for customers to express their needs. That is the necessary first step to satisfying those needs. See the Structural Solutions section.

For instance, proprietary application server projects such as BEA and WebSphere seem deaf to the frustrations of their customers, but the open source JBoss project is happy to hear about those problems and avoid them in its own product.

Standards/Consensus: Open Source projects must conform to, and reuse, accepted, up-to-date standards. Proprietary projects, without the benefit of high visibility or feedback are free to make inferior decisions.

Don’t miss this great essay by Paul Graham: What Business Can Learn from Open Source. And you know what else? I don’t think open source projects use the annual performance review.

Related: Open Source: The Scientific Model Applied to ProgrammingDangers of Extrinsic MotivationWhat Motivates Programmers?Open Source Management Terms

Management Improvement Carnival #47

Read the previous management carnivals. Also see the management Reddit for popular new blog posts to include in future carnivals.

  • The Decline and Fall of Agile by James Shore – “Without XP’s agile engineering practices, code quality and productivity asymptotically decreases over time. With them, productivity starts lower, but then it asymptotically increases.”
  • How Do You Measure Success? by Ron Pereira – “First of all, I believe many companies get caught measuring the wrong things… my favorite productivity metric is sales per employee. Of course some will think I’m advocating cutting heads in order to drive this metric up. I’m not.”
  • No Excuses by John Shook – “A culture of management seeking where to place the blame — the five whos — will absolutely prevent the flourishing of a culture that fosters ubiquitous use of the five whys”
  • Resource Planning by Jurgen Appelo – “Considering that task-switching is bad, the resource planner must seek to minimize the number of different activities per week, per person… Software developers themselves are allowed to reserve a number of academy days. These are days for self-development and training.”
  • The Deming Chain Reaction by John Dowd – “According to Deming, quality is not a state to be achieved in manufacturing, but is, rather, an ongoing company-wide effort at continual improvement.”
  • Continue reading

  • Recent Trackbacks

  • Comments