Downside of “the praise sandwich”

Esther Derby wrote a concise piece on her blog recently about “the praise sandwich”. It was a bit of an eye-opener in that I too have been guilty in the past of something similar, what could be called “the tickle and slap”. Open with some praise, but then there’s the “but”. “Susan, you did a wonderful job chairing that meeting yesterday, a fine job, thank you. However, I’d like to discuss how you dealt with the group disagreements.” 

I like Esther’s approach to constructive and critical feedback – open, describe the behaviour, describe the impact, and make a request. Four steps that are pretty self-explanatory, and easy to remember. This framework can help any of us to deliver feedback to our team members in a way that should be honest, fair and concise. And like she says, don’t oversell it – once the request has been made, it’s probably wise to ensure that the recipient understands the request, but other than that, move on and don’t belabour your point.

Design walkthroughs

Interested in knowing about another way to improve your software quality? This post from Project Smart captures some best practices for design walkthroughs. Although written with designers in mind, design walkthroughs of this type can work equally well for small teams of developers, particularly when making changes to mature, well-established software systems.

By scheduling a design walkthrough for a significant change to the application, be it an enhancement or a major bug fix, a design walkthrough enables the developer to get more eyes looking at the proposed change. By catching design oversights early in the process, it can reduce rework and frustration for the developer, and improve code stability and maintainability in the long-term for the entire team. It also has the benefit of exposing more members of the team to more of the code base.

Working as a senior developer for a small but effective software development team in the ’90s, we countered some quality issues in our software by implementing both design and implementation walkthroughs. The sequence of steps looked something like this:

1. A developer investigates the change required, and comes up with a design for the change – the existing classes involved, the refactoring required, any new interfaces or classes required, and so on.
2. The developer prepares a 20-min overview of the proposed changes and their impact on the current code base.
3. A design walkthrough occurs wherein the developer presents the overview and receives the feedback of the team
4. With the feedback in hand, the developer makes the change, noting where the implementation varies from the proposed changes as they work through any unanticipated changes required as they go
5. An implementation walkthrough is held when the change is complete, which provides the developer and the team a chance to review the change, and to understand any differences between the original change discussed and the implementation delivered in the end.

In this way, working with both a design and implementation walkthrough, a team can make best efforts to “plan-do-check-act” on significant changes to the system, and enhance the long-term viability of the application code base.

Enhancing “the flow” of development

Pawel hits the nail on the head with this post on helping a development team as a project manager. It’s not just about getting out of the way and letting the dev team get on with their work. It’s about actively clearing the way for them, freeing them to do what they do best. It’s about helping them maintain “the flow” of problem-solving and creativity that goes into creating good (if not great) software. To do that well is a balancing act for the project manager. On the one hand, you must buffer the team from the worst distractions and time-consuming tasks tangential to their core work. On the other hand, you have to be careful not to filter so much that they’re not connecting well with other departments, or product owners, or users. 

However, I’m not sure that I agree with Pawel when he says that “if they end up helping you with project management, something is wrong”. That seems a bit too black-and-white in judgement. Often team members may see a risk or issue upcoming, or question the schedule, or another department’s estimates, and their feedback is valuable and noteworthy. Is that “helping you with project management”? I believe it is – and it’s all good. I believe what Pawel is getting at is that, taken to an extreme, asking the dev team to do core PM work, and vice-versa, is counter-productive. Far be it for the project managemer to believe that their role should include coming up with extensive test cases, or coding up a Silverlight application, or designing APIs.

Internalizing external costs

An interesting thought came to mind yesterday in discussion with a colleague of mine over coffee. He is pursuing a path in executive coaching and writing on healthy organizations and leadership. He made the point that, often, companies with poor organizational health and weak leadership don’t pay the price for quite some time – the financial numbers and reports often don’t reflect the long-term impact of the organizational dysfunction.

Our current environmental issues are very much about external costs not being recognized in the actual cost of the service or good produced – societal costs such as pollution, waste, greenhouse gases, and other human negative impacts. I’m a big proponent of allowing the market to find its equilibrium but only after such external costs have been internalized such that the cost of the good sold reflects ALL costs of its production, not just the direct and indirect financial costs. 

So this is where the interesting thought came up . It would be interesting to discuss and explore whether or not a price could be placed on the long-term impact of organizational dysfunction such that it could be reflected in the financial statements, and thus be integrated into the market judgement of the worthiness of the firm? Why must firms that focus on lowering their emissions, or supporting leadership development, or focusing on employee health and well-being, all at their own expense, face a penalty in the market because of lower profits than their peers?

By internalizing the external costs of bad management, could we see a scenario in which all of the costs of running the firm poorly are reflected in the market valuation of the firm? Over the long-term, the true costs are probably reflected in either corporate collapse or a buy-out, but in the short run, it would be more effective if the market valuation had a mechanism for taking external costs into account.

Learning Curves

Mike Griffiths posted on the interesting topic of how we make improvements in our performance, the key point being that an individual’s performance is a function of their behaviour and their environment – or P = B x E. 

Reading this piece by Mike was timely, since I’m currently reading Gerald Weinberg’s ‘Becoming a Technical Leader‘ in which Gerald touches on the performance of leaders as well. Weinberg points out that our learning curves in anything we do (pinball, in his case) are not linear, and in fact, usually see declines in performance before significant positive increments. To quote Weinberg: 

There are plateaus, but you don’t really leap, you climb. In order to climb, you must leave the sure footing, letting go of what you already do well and possibly slipping downward into a ravine. If you never let go of what you already do well, you may continue to make steady progress, but you’ll never get off the plateau.

I’m always excited to be on a learning curve – in fact, I have left jobs when the learning curve flattened out, it means that much to me. Years ago, when working towards my professional mountain guiding exams, a close friend passed along something that he had received from his own mentor. He pointed out that our performance as leaders, both in the mountains and in our careers, is often a game of snakes-and-ladders, our improvements followed by strong doses of humility.

We start learning, we’re initially humbled by those around us with more experience. However, as we develop our own skills and talents, we become more confident and a little less humble. Then, we meet someone else, or take on another significant challenge, and suddenly realize just how little we actually know. It feels like we’re starting again, thus the feeling of playing snakes-and-ladders. However, we’re not starting all over again – we’re experiencing the ravine that Weinberg describes, before climbing up to the next plateau.

I’ve never forgotten that lesson, and everytime I find myself taking on new challenges and pushing myself to take on the next plateau, I think of my old friend. How do you feel about your own learning curve – is it an exponential curve (!) or does it have its own bumps and dips along the way?

The next generation of electric lights

Continuing on earlier blogs about the next generation of lighting, a pet interest of mine, in “A brilliant new approach”  in this week’s edition of The Economist, there’s an update on the latest developments on LED lighting.  LED replacements for our most common residential light bulbs are likely to be in markets far sooner than some think, I believe.

Recent thoughts on Scrum

In a recent discussion with a seasoned veteran in the project management field, I brought up my recent participation in a Certified ScrumMaster workshop. He asked me what I had found of interest in the workshop material.

One interesting item that had come up in the workshop was that there should be no time limits on scrum planning (aka Sprint 0) – within reason. Obviously there should be a balance struck between scrum planning and the team beginning to build product. However, I chuckled when I heard “no time limits” because in a previous position we were informed by the CTO that Sprint 0 should take no longer than a week for a 4-to-6 month project – no ifs, ands or buts. I regret not pushing back harder on this mandate – the length of time required for project planning depends on the complexity of the project requirements, the familiarity of the team with the existing product and code base, and the number of inter-departmental dependencies involved in the upcoming deliverables, amongst a host of other variables. At a minimum, we should have been taking 2-3 weeks to plan and design for a project of that length.

Another point of interest in the workshop was on agile estimation, and on the value of relative estimation instead of absolute estimation in a software development project. Apparently, most of us are pretty poor at making absolute estimates (“The church is 4.25 km past the Highway 2 intersection.”) and a lot better at making relative estimates (“The church is next to the Best Western, just down the block from the new organic food store.”) So instead of trying to determine absolute estimates from a development team in sprint planning, the Scrum framework encourages the development of relative estimates – estimating the overall work of a user story relative to the smallest story allocated to the sprint. Once the team has determined which story is the smallest, involving the least amount of overall work, estimating all of the other stories can be done relative to the smallest task. (In an ideal world. I believe that there are limitations to this – wildly different tasks within the sprint may not enable direct comparisons, for example.)

One downside of this approach, however, is that in the Scrum framework the team is then encouraged to arrive at a consensus of overall effort on each user story – even though they likely began with a range of effort estimates. For a given story, the initial estimates might be between 3 and 30 days. After some further discussion, perhaps the estimates converge to 8 to 15 days. Although some would suggest that the average be used, or that the team continue to discuss the requirements to arrive at a tighter estimate, I believe there is value in those numbers as they stand. Take the range given and plug the range into your schedule and estimation tools. Perhaps use the same tools provided in the Scrum framework to help your team arrive at three numbers (pessimistic, most likely and optimistic) for each user story instead of one number, and then apply PERT analysis on those three. Chances are your schedules will be more realistic as a result. 

Recognize that the quality of a relative estimate is probably better than an absolute estimate, and that a range estimate is always better than an absolute estimate.

What do you think? What have been your positive and negative experiences with software project estimation, and Scrum?

What’s your passion?

Passion | ManagerTools.com

This post on the Manager Tools blog caught my attention because it deals with one of my favourite interview questions – “So what’s your passion? What are you passionate about? What gets you sparked and out of bed on a good day?”

Years ago, when I was joining a small firm here in Calgary, one of the principals asked me the same question. He wasn’t interested in my answer so much as he was trying to see how I would light up and spark on something – it didn’t matter what it was. I took that to heart, and when hiring for a development team in later years, I’ve tried my best to ask the question, and to hire passionate people. 

Some were passionate about their family, others were passionate about their hobbies or sports pursuits, one was passionate about wine, another was passionate about travelling. And yes, some were passionate about their work, about coding or testing or designing or planning. It matters less to you that your team is passionate about work, it only matters that they’re passionate about something in their lives. That’s because, chances are, if they’re fired up and passionate about one thing, you can probably get them fired up and passionate about the project.

Look for passion in your hires – try to see the spark in their eye, the rapid-fire speech, the heightened intensity, when they talk about something of interest to them. Get them talking about their interests, and you’ll see it.

Book Review : The Art of Project Management

I can’t recall the store in which I first picked up Scott Berkun’s “The Art of Project Management” but I do remember that I was quickly intrigued by it, and immediately bought it. The first edition has since been revised and published as ’Making Things Happen: Mastering Project Management ‘. Having read the first edition cover-to-cover, and after repeatedly dipping into specific chapters for a re-read, I can heartily recommend it as a great addition to the library of any project manager, whether you’re a newbie or an old hat.  

I was intrigued by the book primarily because of it’s style. Scott avoids the dry discussions on methodologies and processes and frameworks, and instead delves deeply into more pragmatic topics around project management such as decision making, how to make things happen, and the end-game strategy. With his background in application development management at Microsoft, it’s natural that he writes with a leaning towards managing software development projects, but many of the topics cross over to other applications of project management easily. His writing is easy to read, and most importantly for me, easy to recall later (my memory isn’t what it used to be).

Here are some takeaways of my own from the read that will perhaps give you a sense of the book:

• To Scott’s great credit, he invests two chapters on design and idea generation within project planning – where ideas come from, what to do with ideas once you have them, how to consolidate ideas, prototyping – exploring “the gap from requirements to solutions”. Since many projects fail from poor requirements and design up front, this struck me as a welcome addition to a project management overview. 
• It is interesting that the schedule chapter comes before the chapter on vision, but in the chapter there is a good discussion of three purposes to schedules, how schedules fail, a schedule is a probability, and good estimates come from good design.
• Scott delves into soft skills throughout the book – writing good specifications, specifying is not designing, decision making, management through conversation, relationships, how to get people’s best work (follow advice, inspiring, clearing roadblocks, roles, goals, teaching, asking), how not to annoy people, the benefits of good process, good email, good meetings, leadership and trust. All of this material serves as excellent reminders, and some of it is absolute gold.
• Some of the most interesting reading lies at the end of the book, as he discusses the tactical management of a software development project and writes about what do to when things go wrong, how to make things happen, prioritization, the middle and end game strategy, politics and solving problems, and my personal favourite, flying ahead of the plane.

Looking at the Amazon listing for this book, I agree that the book “doesn’t cite specific methods, but focuses on philosophy and strategy” – perhaps this was the facet of the book that originally attracted me, the more casual tone not unlike a mentor providing sage advice over a mid-afternoon coffee. I know that I’ll revisit the book on a regular basis – it will be ready at hand in my bookcase, and the cover will become ever more worn that it is already.

Better Projects: Agile or Plan Driven?

Craig Brown at Better Projects posted on Boehm and Turner’s earlier writing on balancing agility and discipline today. Which reminded me – there are two papers by Boehm and Turner on this topic, both of which make interesting further reading to Craig’s post. The two papers, if you want to know more, but don’t wish to read the entire book, can be found here and here.

I found interesting reading in the two papers. However, I wondered whether the balance is more truly between agility and predictability rather than agility and discipline. The agile toolkit can still be applied with discipline, but the outcomes may be less predictable.