Saturday, April 14, 2018

Start your project with a Walking Skeleton

Start with a walking skeleton
In order to reduce risk on large software development projects, you need to figure out all the big unknowns as early as possible. The best way to do this is to have a real end-to-end test with no stubs against a system that’s deployed in production.

You could do this by building a so-called Walking Skeleton, a term coined by Alistair Cockburn. He defined it as a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel. A similar concept called “Tracer Bullets” was introduced in The Pragmatic Programmer.

A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.
If the system needs to talk to one or more datastores then the walking skeleton should perform a simple query against each of them, as well as simple requests against any external or internal service. If it needs to output something to the screen, insert an item to a queue or create a file, you need to exercise these in the simplest possible way. As part of building it, you should write your deployment and build scripts, set up the project, including its tests, and make sure all the automations are in place — such as Continuous Integration, monitoring, and exception handling. The focus is the infrastructure, not the features. Only after you have your walking skeleton should you write your first automated acceptance tests.

This is only the skeleton of the application, but the parts are connected and the skeleton does walk in the sense that it exercises all the system’s parts as you currently understand them. Because of this partial understanding, you must make the walking skeleton minimal. But it’s not a prototype and not a proof of concept — it’s production code, so you should definitely write tests as you work on it.

High risk first 

According to Hofstadter’s Law, “It always takes longer than you expect, even when you take into account Hofstadter’s Law”. This law is valid all too often. It makes sense than to work on the riskiest parts of the project first, which are usually the parts which have dependencies: on third-party services, on in-house services, on other groups in the organization you belong to. It makes sense to get the ball rolling with these groups simply because you don’t know how long it will take and what problems should arise.

Making changes to an architecture is harder and more expensive the longer it has been around and the bigger it gets. We want to find mistakes early. This approach gives us a short feedback cycle, from which we can more quickly adapt and work iteratively as necessary to meet the business' prioritized list of runtime-discernable quality attributes. Assumptions about the architecture are validated earlier. The architecture is more easily evolved because problems are found at an earlier stage when less has been invested in its implementation.

The bigger the system, the more important it is to use this strategy. In a small application, one developer can implement a feature from top to bottom relatively quickly, but this becomes impractical with larger systems. It is quite common to have multiple developers on a single team or even on multiple, possibly distributed teams involved in implementing end-to-end. Consequently, more coordination is necessary.

No shortcuts

It’s important to stress that until the walking skeleton is deployed to production (possibly behind a feature flag or just hidden from the outside world) you are not ready to write the first acceptance test. You want to exercise your deployment and build scripts and discover as many potential problems as you can as early as possible. The Walking Skeleton is a way to validate the architecture and get early feedback so that it can be improved. You will be missing this feedback if you cut corners or take shortcuts.


Start with a Walking Skeleton, keep it running, and grow it incrementally.

Read more…

Monday, April 09, 2018

It's never too early to think about performance

Automated Performance Testing
Business users specify their needs primarily through functional requirements. The non-functional aspects of the systems, like performance, responsiveness, up-time, support needs, and so on, are left up to the development team.

Testing of these non-functional requirements is left until very late in the development cycle, and is sometimes delegated completely to the operations team. This is a big mistake that is made far too often. Having separate development and operations team is already a mistake by itself, but I will leave that discussion for another article.

I was recently part of two large software development projects were performance was addressed to late, and the costs and time necessary fixing it was a magnitude larger as it would have to address performance early in the project. Not to mention the bad reputation the teams and systems got after going live with such a bad performance that users could hardly do their daily work with the system. 

Besides knowing before you go live that users are not going to be happy (and therefore should NOT go live) there is another big advantage of early performance testing. If you aren't looking at performance until late in the project cycle, you have lost an incredible amount of information as to when performance changed. If performance is going to be an important architectural and design criterion, then performance testing should begin as soon as possible. If you are using an Agile methodology based on two-week iterations, I'd say performance testing should be included in the process no later than the third iteration.

Why is this so important? The biggest reason is that at the very least you know the kinds of changes that made performance fall off a cliff. Instead of having to think about the entire architecture when you encounter performance problems, you can focus on the most recent changes. 

Doing performance testing early and often provides you with a narrow range of changes on which to focus. In early testing, you may not even try to diagnose performance, but you do have a baseline of performance figures to work from. This trend data provides vital information in diagnosing the source of performance issues and resolving them.

This approach also allows for the architectural and design choices to be validated against the actual performance requirements. Particularly for systems with hard performance requirements, early validation is crucial to delivering the system in a timely fashion.

“Fast” is not a requirement 

"Fast" is not a requirement. Neither is "responsive". Nor "extensible". The main reason why not is that you have no objective way to tell if they're met. 

Some simple questions to ask: How many? In what period? How often? How soon? Increasing or decreasing? At what rate? If these questions cannot be answered then the need is not understood. The answers should be in the business case for the system and if they are not, then some hard thinking needs to be done. If you work as an architect and the business hasn't (or won't) tell you these numbers ask yourself why not. Then go get them. The next time someone tells you that a system needs to be "scalable" ask them where new users are going to come from and why. Ask how many and by when? Reject "lots" and "soon" as answers.

Uncertain quantitative criteria must be given as a range: the least, the nominal, and the most. If this range cannot be given, then the required behavior is not understood. As an architecture unfolds it can be checked against these criteria to see if it is (still) in tolerance. As the performance against some criteria drifts over time, valuable feedback is obtained. Finding these ranges and checking against them is a time-consuming and expensive business. 

If no one cares enough about the system being "performant" (neither a requirement nor a word) to pay for performance tests, then more than likely performance doesn't matter. quote

You are then free to focus your efforts on aspects of the system that are worth paying for.

Automated Performance Testing

In order to keep costs and spend time on performance testing in check, I advise you to automate this as much as possible. Tools like Taurus simplifies the automation of performance testing, is built for developers and DevOps, and relies on JMeter, Selenium, Gatling and Grinder as underlying engines. It also enables parallel testing, its configuration format is readable and can be parsed by your version control system, it’s tool friendly and tests can be expressed using YAML or JSON.

Here are some types of tests you can run automated:
- Load Tests are conducted to understand the behavior of the system under a specific expected load.
- Stress Tests are used to understand the upper limits of capacity within the system.
- Soak Tests determine if the system can sustain the continuous expected load.
- Spike Tests determine if the system can sustain a suddenly increasing load generated by a large number of users.
- Isolation Tests determine if a previously detected system issue has been fixed by repeating a test execution that resulted in a system problem.

Technical testing is notoriously difficult to get going. Setting up the appropriate environments, generating the proper data sets, and defining the necessary test cases all take a lot of time. By addressing performance testing early you can establish your test environment incrementally avoiding much more expensive efforts once after you discover performance issues.

Test Automation & Code Quality Workshop

One very big pain point for software development projects is trying to implement a more or less agile project delivery method without implementing automated tests and test automation. Automated performance testing is part of this.  

That is why Falko Schmidt and myself decided to design a two-day workshop to address this pain point and learn you how to solve it. We have worked together on a number of software development projects for clients like PwC and Helsana. Falko in the role of the lead developer or test automation specialist, myself as project coach or project recovery manager.

We both see test automation as an essential part of modern software development and project success and designed this workshop to spread the word and teach what we have learned over the years.

So ...

- Are you a company that wants to release faster and in a better quality?
- Are you managing a software development effort and your team does not have the skills to automate your testing?
- Are you a developer who would like to improve the quality of his own work?
- Are you tired of fixing the bugs in the code of your colleagues?
- Does your test automation efforts do not bring the expected benefits?
- Do you want to increase your market value and employability as an allround software developer?

Then this workshop is for you!

Have a look at to see in detail what we offer and sign up. The next dates for our public workshop in Zurich are May 24/25 and July 5/6.

When you are interested in an in-house workshop for your team just contact us.

Read more…

Friday, March 30, 2018

Doing the right number of projects

Agile Project Portfolio Management Goals
I have written about project portfolio management extensively and created the Agile Project Portfolio Management Framework. In all my articles I relentlessy repeated the three goals of Agile Project Portfolio Management.

1) Maximize the value of the portfolio

2) Seek the right balance of projects, thus achieving a balanced portfolio

3) Create a strong link to strategy, thus the need to build strategy into the portfolio

After some thinking and new experiences I have decided to add a very important goal.

4) Doing the right number of projects

Getting this one wrong makes it very hard, or even impossible, to achieve the other three. And as you propable allready have guessed, doing not enough projects is seldomly the case.

So what is the right number of projects?

Typically the half of what you are currently doing. Of course the answer of this question is depending on the altitude of your portfolio (i.e. only IT, or your whole company), the size of your projects, and the size of your company. But there are a number of guidelines from the Agile and Lean world that we can use.

PMI project portfolio management is all about value optimization and optimizing resource allocation. Both are designed in such a way, that in my opinion it will result in the opposite. As we have seen in the article about funding, running projects at hundred percent utilization is an economic disaster. Any small amount of unplanned work will cause delays, which will be even worse because of time spent on re-planning. And value is only created when it is delivered and not when it is planned. Hence we should focus on delivering value as quickly as possible with our given constraints.

This brings us to lean thinking. Lean is sometimes described as focusing on smaller batch (project) size, shorter queues, and faster cycle time. Focus on delivering value quickly. Lean is much more than this. The pillars are respect for people and continuous improvement resting on a foundation of manager-teachers in lean thinking. Queue management is just a tool far from the essence of lean thinking. But it is a very helpful tool that can have a very positive impact on your project portfolio management process.

Some example of queues in project and portfolio management?
 - products or projects in a portfolio
 - new features for one product
 - detailed requirements specifications waiting for design
 - design documents waiting to be coded
 - code waiting to be tested
 - the code of a single developer waiting to be integrated with other developers
 - large components waiting to be integrated
 - large components and systems waiting to be tested

In lean thinking, work in progress (WIP) queues are identified as waste, and hence to be removed or reduced, because:
 - WIP queues (as most queues) increase average cycle time and reduce value delivery, and thus may lower lifetime profit.
 - WIP queues are partially-done inventory (of projects in this case) with an investment of time and money for which there has been no return on investment.
 - As with all inventory, WIP queues hide—and allow replication of—defects because the pile of inventory has not been consumed or tested by a downstream process to reveal hidden problems; for example, a pile of un-integrated code.

On a similar note, we typically have a lot shared resource queues in our portfolio. Especially the main know-how carriers in a business unit are shared by multiple parallel projects. These queues are getting bigger due to project re-planning when one of them is behind schedule.

Also consider project portfolio throughput from a cost of delay point of view. You might, for example, be able to complete a project with perfect resource management (all staff is perfectly busy) in 12 months for $1 million. Alternatively, you could hire some extra people and have them sitting around occasionally at a total cost of $1.5 million, but the project would be completed in only 6 months.

What's that 6 months difference worth? Well, if the project is strategic in nature, it could be worth everything. It could mean being first to market with a new product or possessing a required capability for an upcoming bid which you don't even know about yet. It could mean impressing the heck out of some skeptical new client or being prepared for an external audit. There are many scenarios were the benefits outweigh the cost savings.

Additional to delivering the project faster, when you are done after 6 months instead of 12 months you can use the existing team for a different project delivering even more benefits for your organization. So not only do you get your benefits for your original project sooner and/or longer, you will get those for your next project sooner as well because it starts earlier and is staffed with an experienced team.

So what does this mean for your organization?

For a typical organization this means the following five things:

1) Doing fewer projects in parallel (i.e. limit work in progress)). On average only half of what you are doing now. Focus on limiting the number of concurrent projects in your organizational units.

2) Focus on doing the right projects.

3) Keep your project size small (i.e. limit batch size)

4) Focus on improving your project delivery capability.

5) Implement an agile delivery method for projects were it makes sense (i.e. reduce cycle time because you deliver value during the project, and not only at the end)

The Agile Project Portfolio Management Framework

Based on this article series I have written The Agile Project Portfolio Management Framework Guide. Besides this guide I have written many more articles on Agile Project Portfolio Management. You can find those here.

When you need help with setting up your Agile Project Portfolio Management process, or want to have a review of your existing portfolio, have a look at Project Portfolio Review. When you are interested in a workshop on Agile Project Portfolio Management have a look here.

Read more…

Sunday, March 25, 2018

Facing your project's reality

Projects fail for many reasons: optimistic estimates; technology that doesn’t work as advertised; misunderstanding the needs of key stakeholders; plans driven by deadlines rather than feasibility; the belief of the team that given enough pizza they can solve any problem by tomorrow morning.

In my experience, many of these reasons come back to one root cause: we lose touch with reality. A few examples:

- We spend insufficient time exploring and validating assumptions at the start of a project, so we operate from different expectations of what’s required or how they’ll work together. This makes it almost impossible to build meaningful estimates and schedules. The project begins from a position of unrealistic expectations and is playing catch-up forever after. See my article “No validation? No project!”.

- We start with an over-optimistic assessment of our team’s capabilities and skills, or of the technology and methodologies, we are using. Initial slow progress is explained by lack of familiarity. Eventually, the reality of slower than expected progress hits us.

- Sponsors may not realize how much effort and commitment they need to put into sponsorship, or what skills will be required. They may assume that the project manager can handle many of the things that are properly their responsibility. A project with weak leadership will then have trouble connecting to broader organizational objectives.

- We negotiate poorly with key stakeholders. How often have you seen an executive beat down the initial estimate from a technical team? The team thinks they’re estimating, but the executive is conducting a negotiation. At least one person has lost touch with reality in this situation.

- Teams under pressure find it difficult to step back and think about what’s really going on. Minor problems pile up because everyone is so busy that they can’t see the underlying trend.

- Even if we can see the underlying trend, we have trouble reporting it. A culture that says “come to me with solutions, not problems”, may mean that unsolved problems don’t get talked about. A culture where senior managers are expected to have all the answers may mean that sponsors can’t admit it that they don’t understand what their project manager is saying. Often we just don’t know who to go to with their observations. People with problems have trouble connecting to people who may have solutions, and the project’s leadership remains disconnected from the real situation.

- And, of course, many of us don’t even want to think about what the real risks of the project might be.

This doesn’t happen because we are lazy, or because they are trying to sabotage their projects. Skills and experience may provide some insulation, but they don’t eliminate the problems completely. We lose touch with reality for reasons rooted in basic psychology. They are called cognitive biases. There are many of them, and most could impact your project. I will discuss the, in my opinion, most "dangerous" ones.


"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts” – Bertrand Russel

We tend to overestimate our own ability. Surveys show, for example, that most of us consider ourselves to be above average intelligence, or to be better software developers than average, or to be better project managers than average. Likewise, most consultancies and system integrator claim a significantly higher success rate than the industry average. This specific effect of overconfidence is known as the Dunning-Kruger effect.

Overconfidence is a direct cause of underestimation on many projects. It helps driving phenomena like scope creep (developers think they can implement a feature with little effort) and the famous ninety-ninety rule.

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." - Tom Cargill, Bell Labs


"Everything should be made as simple as possible, but not simpler" – Albert Einstein
We tend to use simplifying assumptions and mental model in order to deal with complexity. This is sometimes essential, for example when rapid decision making is important, but it can lead to unintended outcomes very fast. Most of us have been caught by time, cost and complexity estimates that escalate as we get further into the details. Yet most big projects are started with very broad, “high level” estimates.

Likewise, we often operate from mental models for how projects, teams or organizations should work. These are simplifications of reality; they embed large numbers of assumptions. If we use them unthinkingly, we fail to recognize situations where the assumptions are violated. We begin to operate in model land rather than the real world. Anybody who has done some work with one of the MBB management consultants should have experience with this. Not to mention the software and solution architects that have not done any real work since switching to PowerPoint architecture. 

When we fail to recognize the true complexity of our projects, their requirements and the organizations that they are serving, we accept an unrealistic scope, estimates, staffing, and plans. We also fail to recognize and manage key risks.

Avoiding Pain

“Pain in this life is not avoidable, but the pain we create avoiding pain is avoidable” – RD Laing

We tend to avoid pain. I am not talking about physical pain, but emotional pain. Sometimes this means deferring immediate pain at the risk (or even certainty) of needing to deal with greater future pain. For example, rather to face up to a tough conversation now (“it probably can’t be done”), we take high-risk options (“the only way it can be done is if we cut all these corners and hope for the best”). Likewise, rather than going through the pain of admitting that we have been delayed, we find reasons to persuade ourselves that we will catch up by the next milestone. Like that will ever happen…

The pain we are avoiding comes from a variety of sources and is very much depending on your personality.

- We may be avoiding confrontation, anger or disappointment. This is why so many of us have trouble saying “no”. We would rather fail later than deal with anger or disappointment now. Especially with people we love, like, fear and/or respect.

- We may be avoiding the feeling for the loss of control or mastery. We may focus on tasks we are good at, rather than those that are important. Technical people often derive a lot of their identity from their ability to solve problems. Admitting they can’t solve a problem represents a deep threat to their sense of identity. Project managers who like to feel in control of the situation (which they never are), may avoid finding out or understanding things they can’t control (which are almost all important things in a project).

- We might be avoiding cultural taboos. Some teams and cultures have difficulties saying “no” because it is just not something you do. There are string cultural pressures to make “positive” responses. Many organizations find it difficult to discuss risks for similar reasons. There is a strong pressure to “smile, it probably never happens”.

- We might be avoiding loss of “face”. For example, senior managers find it difficult to admit their ignorance to the people reporting to them. Rather than seek clarification to status reports, they may allow things to drift. This is a common reason for weak project sponsors and steering committee members. They simply do not know how to help and do not want to ask. Strong project managers can manage/engage their StC and sponsor, but inexperienced project managers, who are most likely to need support themselves, can find this hard to work with.

- We may be avoiding apparent costs. Spending time to clarify objectives; allocating time to risk mitigation activities; undertaking further analysis of the problem; performing independent reviews and assurance. These all involve immediate costs with uncertain paybacks. There is often a string pressure to avoid these immediate and obvious costs in order to reduce the budget.

Confirmation Bias

“We tend to accept information that confirms our prior beliefs and ignore or discredit information that does not. This confirmation bias settles over our eyes like distorting spectacles for everything we look at." - Kyle Hill

We tend to look for evidence that confirms our existing hopes and beliefs. We want, for example, to believe that our project is on course so we seek evidence that shows we are hitting milestones and ignore information that shows where we are behind schedule. As a team makes commitments to budgets, estimates, schedules, and deliverables, this bias becomes more embedded. They begin to focus their energy on finding ways to achieve these commitments and to avoid any signs of problems or risks. The opposite can happen as well. As soon as a team believes the project will fail, it most probably will, because they will focus on finding reasons why it will.

Confirmation bias is often built in our project approval process. People say what they think they need to say in order to get the projects they believe in approved. They may not lie, but they focus only cursory attention to the costs, risks and side effects. This then becomes the approved version of the project’s storyline, to become embedded in people’s thinking through repetition.

Availability cascade

"Vision without execution is hallucination." - Thomas Edison                    
The availability cascade is a self-reinforcing process in which a collective belief gains more and more plausibility through its increasing repetition in public discourse. If we hear a message often enough, we begin to believe it. This is the basis of most marketing and propaganda. Eventually, we may end up believing our own propaganda. A team takes initial, rough estimates and works with them, gradually losing sight of the fact that there is little basis behind them; a manager repeats the high-level vision to all who will listen and starts to mistake the vision for delivered reality.

Perceptual Bias

“How does a project get to be a year late? One day at a time” – Fred Brooks
We often find it harder to recognize gradual trends than sudden changes. We get locked into our view of individual details rather than seeing the big picture. When we are under pressure we see those days as individual, disconnected events and lose track of the bigger trend towards disaster.

Anchoring Effect

You've seen the anchoring effect in action a million times, usually in the form of a suggested retail price. When you see a purse with a price tag that claims it normally sells for $400, but is marked down to $200, that little "yippee!" you feel inside at the prospect of getting a bargain? The anchoring effect. The seller simply told you that the purse was worth $400, and we tend to accept this line of bull because we are basically trusting people and trained to use price as our gauge of value.

Anchoring is a cognitive bias that describes the common human tendency to rely too heavily on the first piece of information offered (the "anchor") when making decisions. During decision making, anchoring occurs when individuals use an initial piece of information to make subsequent judgments. Once an anchor is set, other judgments are made by adjusting away from that anchor, and there is a bias toward interpreting other information around the anchor.

So you can imagine now why your first rough estimations are maybe not so harmless.

Reinforcement Loops

All the above described biases often combine and reinforce each other. We want to believe that we are above average at what we do, so confirmation bias reinforces our overconfidence. As we continue to confirm how good we are, repetition bias adds further reinforcement. This growing overconfidence makes us more prone to use pain-avoidance strategies. We assume we will be able to solve any problems, so we do not face up to potential difficulties or invest in analysis and risk mitigation. It is cheap to fly in two independent experts to validate your solution architecture for your multimillion software development project compared to finding out later that your design will not work and you could have known this from the get-go. Those experts might even have some other great tips and tricks as well.

Organizational Accelerators

“The limits of my language means the limits of my world.” - Ludwig Wittgenstein

On top of the biases and their reinforcement loops, we have the organizational culture that can make things worse.

Organizations that focus on looking for blame instead of solutions increase the pain associated with admitting problems increasing the chance that people will hide them till the very end. Strong hierarchical organizations can increase the pain associated with confrontation or loss of face (think Yakuza), making it difficult for people at a different level to admit their uncertainties to each other. Organizations with a strong collegial culture have a higher risk of “groupthink”, the tendency for people in a group to converge on consensus at the expense of critical examination.

Projects that span organization boundaries face additional challenges. You have to deal with not one, but multiple cultures. This is especially true in joint ventures and outsourcing relationships that involve multiple organizations. But is also effects projects working across group and unit boundaries within a single organization.

People may be uncertain as to what information can be shared or how it should be shared. Different professional backgrounds, languages and conventions may make it difficult to understand the information that is shared.

Contracts and legal concerns can create further barriers. Penalty clauses, for example, may help align objectives across organizations, but they also create incentives to hide problems and to be very reluctant in supporting change. Procurement regulations may restrict what information can be shared at key stages in the project. All these barriers can make it harder for people to uncover and deal with all the biases described above.


Underlying all this, reality does not always gives us the message we would like to hear. We do not want to hear that we are less intelligent than we would like, or less capable of solving problems, or that we code too slowly. Project failure is one of the prices we pay to avoid (or at least delay) hearing these messages.

Eventually, however, our projects come face-to-face with reality. Something will happen that we cannot ignore anymore. Unfortunately, by the time this happens, it is often too late.

This is why project reviews exist. They are a way to help teams, sponsors, project managers, or other stakeholders manage these human biases and keep in touch with what is really happing on their projects. Of course, they are not the only way. Test automation, project validation, iterative delivery, financial controlling, real estimations, pair programming and many others will help reducing the biases. But every now and then a project review can save you many headaches.

Read more…

Tuesday, March 20, 2018

Five types of reviews for projects

Project Review, Project Audit, Project Retrospective, Gate Review
Reviews can serve a wide range of stakeholders and fulfill a variety of roles. It’s therefore not surprising that organizations undertake several different types of review on there most important projects. From my perspective, there are five distinct types of review. Each with its own focus and outcome.

1) Project Review: Can happen at any point through the project. It checks progress against the original schedule, budget, and deliverables. It looks at the effectiveness of the team, project management, engineering practices, and other related processes. It typically delivers some sort of assessment of the likelihood of project success and identifies areas of concern and corrective actions. This kind of review is also known as a Project Healthcheck or Project Evaluation. These are the kind of reviews I mostly do. Typically as part of a project recovery process.

2) Gate Review: Happens at the end of a project phase or at some other defined point in the project’s lifecycle. It typically represents a decision point, using the outputs from an evaluation to decide whether continued investment in the project is justified.

3) Project Audit: An objective evaluation by a group outside the project team. A project audit is about being compliant and about the now. An audit aims to show the extent to which your project conforms to the required organizational and project standards. So, if your organization uses PRINCE2 or their own project management methodology, an audit will look at how closely you follow the processes. An audit can take place during or after the project.

4) Project Retrospective: Happens as the project closes down. It assesses the overall success of the project and identifies what did or didn’t work during its execution, generating lessons learned for the future. Also known as Postmortem or Post-project Review.

5) Benefits Realization Review: Happens after the organization has had some chance to use the outputs from the project. It evaluates the extent to which the benefits identified in the original business case have been achieved.

Read more…

Monday, March 19, 2018

How to do a project delivery team review

Project Delivery Team Review
In my experience, most issues that arise in software development projects are people issues, not technical ones. DeMarco and Lister showed this in their highly recommended book Peopleware: Productive Projects and Teams already two decades ago, and many others after them as well. Successful projects consistently give significant weight to the human factor.

An important part of the project reviews I do is the project delivery team review. The project delivery team consists of the project team (developers, testers, solution architect, business analysts, and so on), the project manager, project management office and line managers. Stakeholders, sponsor, and Steering Committee are not part of this project delivery team review. These are covered in a separate review because the focus there is a completely different one. From here on I will refer to the project delivery team just as the team.

When reviewing a team I usually look at three levels:

1) Team performance
2) Project management
3) Team members

These are not three separate reviews, but rather three overlapping perspectives of the team, which are part of a single review. While a substantial part of the interviewing can be performed concurrently, information from the review of team performance will provide input to the project management review, which will then provide input for the team member reviews. This will be discussed in detail in the following sections.

Team performance

I start with a review of the project delivery team and focus on the performance of the team as a unit. Interview the initiating manager to get a general perspective of the team, and then meet with the project manager and other parties who interface regularly with the team (interviews can be conducted with multiple participants). The following list covers ten key issues that should be considered during your review and resulting interviews:

1) General team performance: Look at the team as a single unit. How well does the team perform? Are team activities well coordinated, and do team members cooperate well with each other? Look at the team’s accomplishments. Were they due to teamwork, or would individual team members working on their own have achieved them in any case? Look at the team’s setbacks: Could better teamwork have prevented them? How has the team performed over time? Has performance improved or declined?

2) Skill set: Look at the skill set necessary to deliver the project: Does the team have these skills? Does the team have the necessary experience? Are the team member’s skills up to date? Does the development organization have a training program for software developers, and if so, is the team taking advantage of the program? See my article "14 Essential software engineering practices for your agile project" for more background and ideas.

3) Unstaffed positions: At this point, we are not yet looking at understaffing (budgeting for a team that is too small to deliver the project); rather, we are looking at budgeted team positions that have not been filled. Are all approved team positions staffed? If not, for how long have unstaffed positions been empty? Is the project manager constantly looking for new people to fill empty positions? Are the right people in the right roles? Are positions part-time staffed that should be fulltime staffed?

4) Size of team: Look at the size of the team that has been budgeted in relation to the amount of work to be done. Is the team understaffed (too small)? Is the team overstaffed (too big)? Note that in some cases, overstaffing can be a problem (redundancy, overlapping responsibilities, greater management overhead, budget used for the wrong things). How bad is the understaffing or overstaffing?

5) Development facilities: Look at the facilities and tools available to the team. Does the team have the necessary development tools to deliver the project? Do team members have an appropriate workspace, desks, chairs, powerful laptop/pc, 2 screens, and meeting rooms? Does the team have the necessary communications facilities (chat, Kanban board, whiteboards, flipcharts)? Does the team have enough support (administrative support, technical support, PMO)?

6) Organization of team(s): Is the software being developed at a single location, or is it a distributed team? How is the team distributed (different offices, different companies, different countries, offshore, nearshore)? How is the team mixed (internal vs external, location vs location, junior vs senior)? Does the mix and/or split make sense? Would it not be better to have one team at one location? Is the team a feature team or a component team? See my articles "Agile Team Organization" and "Outsourcing technical competence" for more background and ideas.

7) Team atmosphere: Clearly, the failure of a project will affect the morale and spirit of the team. But is there anything else that is causing low morale (if so, what is it)? Is there a lack of commitment to the project. Do team members seem to like each other, goof off together, and celebrate each other's success? Do team members hold each other accountable to high standards, and challenge each other to grow?

8) Relationships with other groups and teams: Look at the project team’s relationships with other external groups and teams. How well do they work with the infrastructure team, the independent test team, the field support team, the architecture team, stakeholders and other projects?

9) Conflicts: Are there any internal or external team conflicts or tensions that could disrupt the project? How long have they existed? How severe are they? Have there been attempts to resolve them? How did this go? Are there issues/opportunities the team isn't discussing because they're too uncomfortable?

10) Management: How good is the relationship between the team and management (the project manager and line management)? Is line management aware of the team problems? Have there been any attempts to resolve the problems? Have the managers responsible for the project been changed recently or frequently? Does line management still support the project and the team?

These ten points are not distinct, meaning that they do not need to be covered separately (they are not a checklist in the sense that you finish one and move on to the next). The review, interviews, and meetings can cover a broad range of topics at a single session, and some of the topics can be discussed concurrently. Use the input from the team performance review to prioritize the later interviews with the individual team members and the other project stakeholders. This way you will be able to put the main pieces of the picture in place more quickly. Reevaluate the priorities after each interview or meeting, and be prepared to repeat interviews when new questions and information comes on your path.

Project Management

The project management review focuses mainly on the leadership (not the administrative / PMO) aspects of the project and considers the main problems confronting the project manager and the way they are handled.

Very often, project managers are the first to be blamed for a failed project. It is important, however, to remember that projects fail for many reasons, several of which are unrelated to the qualities of the project manager. You should approach the review with no preconceptions. Although senior management may sometimes instinctively blame project management, it is your responsibility, after examining the facts, to independently determine if there are any major incompatibilities between the qualities of the project manager and the needs of the project. This is especially important because of the personal impact of your evaluation results.

1) Skills: Look at the main skills required for the project (avoid a comprehensive wish list for an ideal project manager). Concentrate on core skills without which it is clear that the project manager will not be able to successfully lead the project. Does the project manager have these skills? In my opinion for a software development project these skills consist of:

- a good understanding of the software development process
- a good understanding of the business and the business problem that will be addressed
- leadership skills
- project management skills

2) Relationships: How do others perceive the project manager’s ability to successfully lead the project? Look at the quality of the project manager’s relationships with the following groups:

- Team: Look at individual relationships, respect as a leader, and loyalty. Have there been any severe conflicts?
- Senior management: Look at individual relationships with key managers, issues of respect, and confidence in the project manager’s required capabilities. Have there been any severe conflicts?
- Other groups: Look at the working relationship with project support groups, such as the test group, quality assurance, field support, marketing, other projects, and so on.
- Other project stakeholders: In addition to senior management, look at the relationship with customers, users, investors, sub-contractors, partners, and so on.

Have any of these relationships contributed to problems? If other project problems are solved, does the disturbed relationship(s) still endanger project success? See my article "10 Principles of Stakeholder Engagement" for more background and ideas.

3) Confidence in the project: Is the project manager confident that the project can be realized? Is doing the project worth the effort? In the project manager’s opinion, what are the top three well-defined things that need to be done to get the project done?

4) Spirit, motivation, commitment: How committed is the project manager to the success of the project? Look at the project manager’s personal identification with the project, the amount of time invested in the project (full time, part-time, and so on), loyalty to the project team, and more generally the level of enthusiasm in making the project a success. Clearly, much of this is related to the previous point.

5) Other problems: What other problems related to the project manager may have contributed to a negative impact on the project? Consider, for example, personal problems or sickness.

6) General capabilities: Based on points 1 to 5 look at the project manager’s overall ability to successfully manage the project (leadership, personality, competence, and so on). Concentrate only on major points (remember that this is not a performance review). Ask the following question: If other project problems (that are unrelated to the project manager’s work) are solved can the project manager lead the project to success?

Team Members

This review will identify team member problems that can prevent the project from being successfully completed. This is achieved through individual interviews that focus on the team problems identified during the team unit review. It is important to remember that this is not a performance review for the team members, and it is not concerned with problems that will not affect the overall success of the project.

If the team is large, there may not be sufficient time to meet with all team members individually—in such cases, select the ones relevant to the main team problems that have already been uncovered.

The following list includes seven key points to be considered during the individual team member interviews:

1) Role: Determine the team member’s official job function, his/her description of their role in the project, and compare it with the role as described by the project manager. Are there significant discrepancies? When the person's role is ScrumMaster have a look at the ScrumMaster Checklist.

2) Skills: Does the team member have the skills necessary to perform the project team role (avoid a comprehensive wish list and concentrate only on the main skills)?

3) Achievements and contributions: Look at the results (not effort) of the team member’s work on the project so far. What have been the main contributions to the project? Have the team member’s activities been a factor in the success/failure of the project? If so, how big is this factor?

4) Relationships: Look at the team member’s relationship with other persons involved in the project, including:

- Other team members
- The project manager
- Members of other groups/teams
- The project stakeholders

Are any of these relationships problematic? If so, how serious are the problems and how do they affect the project?

5) Morale and commitment issues: Does the team member have any motivation issues that go beyond the situation of the project? How committed is the team member to the project and especially to the attempt to bring it to success? Can the team member be expected to stay with the project if a recovery plan is implemented?

6) Other problems: What other problems have affected the team member’s work on the project? Look at issues such as work environment, tools and facilities, training, and personal problems.

7) Capabilities: Based on the points (1 to 6) look at the team member’s overall ability to successfully perform the role. Concentrate only on major points. Ask the following question: If a new project plan is implemented, will the team member be capable of successfully fulfilling the requirements of the, potentially new, role?


As described in the previous sections there are several sources of information, and three different levels, for the evaluation of the project delivery team. The goal of the project delivery team review is to combine the information to form a single coherent view of the team. I usually do the following:

1) Complete and write down my view of things, identify information/evidence gaps and identify contradicting information. 

2) Archive all interview minutes/recordings, received documents, written documents, and all related emails. This will save substantial time if the findings ever need to be re-examined.

3) Prepare a short team overview document. The document should be no more than 3–6 pages (depending on the size and complexity of the team) and should take between two and four hours to prepare. Include the main sources of information, the list of interviews, the reasoning that led to any significant findings, and any problems or incompatibles that arose during the evaluation.

4) Review the overview with the initiating manager. Review a draft of the document with the initiating manager. Expand any key points that are unclear and correct any factual errors.

5) Adjust the evaluation. Additional information about the team may well continue to emerge throughout the disentanglement process. If any of the new information affects your main findings, be prepared to adjust your conclusions. However, avoid frequent changes to your findings, especially when the new data does not significantly affect your key conclusions.

Due to the information on individual team members, the team overview document cannot be considered a public document. However, a summary of the findings should be available to the team and to the project stakeholders (consult with the initiating manager regarding any business reasons to limit distribution).

Read more…

Saturday, March 17, 2018

Official launch test automation and code quality workshop

So I have written many times about test automation, automated tests, continuous integration, technical competence, DevOps and so on. This because with many of my project recovery engagements these are part of the problem.

One very big pain point is typically trying to implement a more or less agile project delivery method without implementing automated test and test automation. 

That is why Falko Schmidt and myself decided to design a two-day workshop to address this pain point and learn you how to solve it. We have worked together on a number of software development projects for clients like PwC and Helsana. Falko in the role of the lead developer or test automation specialist, myself as project coach or project recovery manager.

We both see test automation as an essential part of modern software development and project success and designed this workshop to spread the word and teach what we have learned over the years.

So ...

- Are you a company that wants to release faster and in a better quality?
- Are you managing a software development effort and your team does not have the skills to automate your testing?
- Are you a developer who would like to improve the quality of his own work?
- Are you tired of fixing the bugs in the code of your colleagues?
- Does your test automation efforts do not bring the expected benefits?
- Do you want to increase your market value and employability as an allround software developer?

Then this workshop is for you!

Have a look at to see in detail what we offer and sign up. The next dates for our public workshop in Zurich are May 24/25 and July 5/6.

When you are interested in an in-house workshop for your team just contact us.

Read more…

Wednesday, March 14, 2018

The five principles of project success

Just finished reading the book "Performance-Based Project Management" from Glen B. Alleman. You might know him from his very popular blog on project management "Herding Cats", which I love and recommend reading. He writes great in-depth articles and has very interesting views on project and risk management.   

Whilst reading his book I found lots of things I see the same, but just as many things that I cannot imagine practicing on the type of projects I work on. I am not sure if I would disagree yet. I am absolutely not familiar with doing projects for the American Department of Defence or NASA so working with Earned Value Management might work there. I have to think a while on how I could translate this into something workable for large financial modeling projects, building an online insurance portal, or building a new intranet/extranet for a professional service company. This is something for a future article.    

One chapter where I was just nodding in agreement and recognition was the chapter "The five immutable principles of project success". These five immutable principles are applicable to every project in every business and technical domain. That is the definition of immutable - they never change and are universally applicable. 


Project failure starts when we can’t tell what “done” looks like in any meaningful way. Without some agreement on our vision of “done”, we’ll never recognize it when it arrives, except when we’ve run out of time or money or both. We’ve all seen the project failure numbers before. We’ve all been told how bad things are. We’ve all heard that large numbers of projects fail because of poor planning or poor project management. Whether this is true or not, how can we increase the probability of our own project’s success?

First, we must recognize that without a clear and concise description of done, the only measures of progress are the passage of time, consumption of resources, and production of technical features. These measures of progress fail to describe what business capabilities our project needs to produce or what mission we are trying to accomplish. Capabilities drive requirements. Therefore, without first identifying the needed capabilities, we cannot deliver a successful project, and we will end up a statistic like all the other failed projects.

With capabilities as our starting point, we’re now going to look at the Five Immutable Principles of project success as they apply to any project, in any domain, using any project management method and any project management tool. 

Five principles

The Five Immutable Principles are best stated in the form of five questions. When we have the answers to these questions, we will have insight into the activities required for the project to succeed in ways not found using the traditional process group’s checklist, knowledge areas, or canned project templates.

1) What does “done” look like? We need to know where we are going by defining “done” at some point in the future. This may be far in the future—months or years—or closer—days or weeks from now.

2) How can we get to “done” on time and on budget and achieve acceptable outcomes? We need a plan to get to where we are going, to reach done. This plan can be simple or complex. The fidelity of the plan depends on our tolerance for risk. The complexity of the plan has to match the complexity of the project.

3) Do we have enough of the right resources to successfully complete the project? We have to understand what resources are needed to execute the plan. We need to know how much time and money are required to reach the destination. This can be fixed or it can be variable. If money is limited, the project may be possible if more time is available and vice versa. What technologies are needed? What information must be discovered that we don’t know now?

4) What impediments will we encounter along the way and what work is needed to remove them? We need a means of removing, avoiding, handling or ignoring these impediments. Most important, we need to ask and answer the question, “How long are we willing to wait before we find out we are late?”

5) How can we measure our progress to plan? We need to measure planned progress, not just progress. Progress to plan is best measured in units of physical percent complete, which provides tangible evidence, not just opinion. This evidence must be in “usable” outcomes that the buyer recognizes as the things they requested from the project.


It does not matter what approaches you take to manage and deliver your project. The five principles are valid and the questions that follow from it should be answered when you want to have a good chance at success. When you have not done so yet look at the current project you are involved in and answer these questions, or when you have some time to think and review on past projects take a successful one, and one or two failed ones and answer these questions. I did the same exercise, and it validated what Glen has written in every way.

I have written a previous article about project success where I address numbers 1 and 5 in a different way. The message is the same. When you do not know what success looks like, and do not know how to measure it, you will have a very hard time having success.

Read more…