I found a small book at an airport recently called “The Decision Book: Fifty models for strategic thinking”. It’s a nice easy read and a good thought provoker, and one of the models in particular really spoke to me.
The Drexler/Sibbet model covers how to turn a group into a team. It specifies 7 distinct stages that a team will generally go though, and the unique issues that can arise at each stage.
Internal employees have context. They have worked inside an organisation for potentially many years and surely know the business better than anyone… so why hire consultants? There are a number of factors that can allow an external consultant to be a bigger agent for change than internal employees, and I’ll go into them here:
Consultants have industry knowledge
Whereas long term employees may think that the way things are done in their company makes sense, they don’t have the wide ranging experience to be able to see the best practices used elsewhere.
Consultants can zoom out
Any internal employee will see their company through the lens of whatever their particular role is within the organisation. Accounts people will have ideas that could help with cash flow, technical people will have technical ideas, etc… but very few of them will be able to look at the big picture and put all of these ideas in context for the maximum possible return on investment.
Consultants can point out the sacred elephant
In any company, you will have things that seem strange to new people, but that everyone else tells them is there for a reason, and so is soon taken for granted as part of the status quo. This might be an antiquated policy or procedure, and may have been the right thing to do when it was 1st conceived of, but may no longer make sense. A new employee will feel pressured to “fit in” and will likely put up with this, but a consultant knows he or she will soon be gone, and only has a limited time-box to make effective change, so is much more likely to challenge this “Sacred Elephant” in the room.
Consultants are new and shiny and their opinions matter
A consultant is only brought in when there is a problem to be solved. They are expensive, and only there for a limited time, and so they are given a lot of power, and anything they recommend is carefully considered, and never discarded lightly. This helps to dispel some of the organisational inertia that often paralyses internal staff from being able to make any meaningful change to an organisation.
Consultants are sometimes brought in to give more weight to an argument that already exists
Change is expensive and energy intensive, and so sometimes a business might already be getting very good advice from internal staff to make a necessary change, but they often are not able to overcome the natural inclination of management to resist changes to the status quo. This is not a dig at managers… if they said yes to every idea their staff had, they’d spend all of their time in churn and pulling the business in countless, often incompatible, directions. However, if a consultant comes in and backs up an idea already proposed, so long as they are able to provide confidence that it makes sense and aligns with the company’s bigger goals, they are often able to push those ideas through.
The larger a Scrum team is, the more opportunity for wastage there is, and so the more difference a good Scrum Master makes.
A team with a bad Scrum master can feel powerless, floundering, isolated, and overwhelmed whereas a team with a good Scrum Master generally feels well informed, connected, directed, powerful, and like they are working at peak effectiveness.
Be punctual
Set a regular cadence for the team.
The daily scrum is always at a predictable time so no time is wasted trying to organise it every day. The larger the team, the more important this is.
This of course also applies to the Review, Retrospective, and Planning meetings too.
Set a strict agenda
Tangent topics will come up regularly during meetings, and although sometimes these can be important discussions, they often take up a lot of time. Make sure that there’s never a time when 2 or 3 people are talking and everyone else is phasing out. If it’s on topic for a Scrum meeting, everyone should be involved, otherwise it should be taken offline (after the meeting with just the relevant people).
Make sure that someone takes a note of these topics as they can sometimes be forgotten otherwise.
Help your team
The people who know best how to make software are the people actually making it. If they raise an impediment, take it seriously and work towards a solution.
Help to motivate the team by showing appreciation for quality work. Doing this publicly often helps motivate other team members to strive towards the same level.
Encourage collaboration amongst team members. If one person is stuck, help them to realise that it’s always ok to ask for help.
Protect the team from excessive scope change. Adding a last minute Product Backlog Item (PBI) to a sprint should only be allowed if the team can drop an equivalently sized one.
Minimise WIP (work in progress) by encouraging the team to finish each PBI before picking up another whenever possible. This helps to minimise multitasking and ensure granular delivery of value to the stakeholders.
Help your Product Owner (PO)
A good Scrum Master should help the PO effectively communicate his requirements and priorities with the team. He should then reinforce those priorities and encourage the team to work in priority order whenever possible.
It’s a good idea to have high level conversations with the PO on occasion to work out what their more abstract goals are so you can help by making micro decisions for the team when appropriate. This way you can occasionally act as a Proxy-Product Owner when needed.
Make sure the Product Owner creates well fleshed out PBIs with easy to understand Acceptance Criteria.
Ensure that the team has a uniform understanding of the estimation method being used (we use 2-Small, 4-Medium, 8-Large, where a Medium is about a day’s work)
The difference a good Scrum Master makes is well documented, and if you follow the above guidelines, you should be well on your way to empowering your team.
Along with my brother, I made a video on this topic which explains how the Scrum Guide defines the role of Scrum Master:
The sunk cost fallacy is in action every time you:
Sit through a long boring movie even if you decided after the first half an hour that is was terrible
Finish a meal that tastes bad and after you’re already full
Continue a bad relationship or friendship, purely because of the time and energy you’ve invested in it so far
Put simply, it’s the motivation to continue on a bad course of action, where logically the future does not look bright, only because of the time/money/energy you’ve put into it up to that point.
These already spent costs, that cannot be recovered, are known as “sunk costs”, and there is a strong human resistance to giving them up. It feels like admitting failure. But being able to be agile and “pivot” when needed is the mark of an intelligent business, and the sunk cost fallacy is generally the main thing in the way of that.
A pivot is when, part way through developing a product or service, you decide to take it in a different direction than the current planned path. This might mean changing the main focus of the offering, or even making it do something completely different to the original plan, and should be informed by early feedback as much as possible.
The problem with the sunk cost fallacy is that you end up investing much more than necessary in to whatever you’ve sunk the costs into, leaving you with fewer resources to go down productive paths. For example, if you’re stuck in a bad relationship, you can’t open yourself up to a future good relationship. And if you’re constantly paying for ongoing product development on a dead product, you can’t be working on a useful product instead.
All you’re doing in this case is throwing good money after bad… but there’s a silver lining. What you’ve paid for up to this point isn’t all wasted. The validated learnings you have gained will stop you from repeating the same mistakes. You have tested the market, an idea, or a product line, and you’re better positioned for your next endeavour.
I’ve been at SSW, a medium sized custom software consultancy, for over 10 years, and in that time I’ve asked for a number of SQL Reporting Services reports to be made, but due to the difficulty in getting exactly what I needed out of the developers, I still had to make many decisions based on best guesses.
In the past year, since I’ve had access to Power BI and can make many of the required reports myself, this has sent me down a serious rabbit hole of discovery into what metrics I really need to run a software consultancy.
So here are the most important reports that I think every consultancy should have.
Financial Reports
Every responsible business owner / General Manager needs to keep their finger on the pulse of the financial health of their business. It’s also important to be able to drill down by both time (years, quarters, months) and expense types (salaries, fixed costs, variable costs, etc) to investigate anomalies.
Utilisation
As a services based business, how many hours you bill vs how many salaries you’re paying is a very good success marker. Keep track of how well each of your employees and offices are going with a Utilisation report. I’t s a good idea to look at this kind of report monthly to ask questions like:
Should I hire / fire someone to grow / shrink one of the offices?
If some people have low utilisation, can they be up-skilled, or is there a good reason that they need to work on internal things?
Client Overview
Your employees will need a nice easy way to get up to speed on the history of a particular client when they join a project or are speaking to them about potential new work. An Overview Report like the one above is a good way for them to get acclimatised. It shows:
When / how much previous work has been done
Who did that work
What projects have been worked on
What technologies those projects are/were built in
Technology (i.e. Income Streams)
As a software development company, our main way of splitting up income streams is by project technologies, but for you this could be any way of splitting the service you’re offering by skill types. The importance of this report is it allows us to know what technologies we should be focusing on with new hires, internal work, or up-skilling. For example, we can tell from the Trends visualisation on the top right above, that SharePoint is becoming less relevant for us, and Dynamics CRM work is becoming a larger proportion of our income.
Current Sales Opportunities
As a services company, you’re probably dealing with a relatively small number of high value companies, and it’s vital that your sales process is strong to keep work coming in. This report shows which of your sales people are dealing with which opportunity, and where those opportunities are coming in from. This report is the reason we opened up an office in Victoria, as we could easily see that there was enough demand there to justify it.
Booked in Days (Forecast)
In order to run a services company, you need a service calendar so you know who is available for client work and who’s already booked in or on leave. We use Dynamics CRM but built our own “booked in days” report as the out of the box one was hard to use. This was built in SQL Reporting Services, but will soon be redeveloped in Power BI.
The Rest
We have other reports that we use to drill down on a lot of the above info, such as conversion rates reports to see how successful our sales process is, or detailed invoicing and receipting reports to see how our clients are paying us and who are main clients are, but the above 6 will get you most of the way there.
Do you have any others that you think I should make? Please let me know in the comments below and I’ll see what else I can spin up.
Every software product in development has a Product Owner who is in charge of supplying the requirements, and it is often misunderstood how important this role is. You can have the best engine in your car (the development team), but if you steer in the wrong direction, you’re not going to get to your destination.
Here are seven tips to make sure you’re doing this job well:
Represent the business
As the Product owner, it is your job to take requirements from any other business stakeholders, your own direct manager, feedback from the developers, and also the actual users of the software, and order them into a single funnel of prioritised work for the development team to work from. This is called the product backlog and is the main tool through which you can influence the success of the team.
Talk to the stakeholders
As well as taking requirements from the business, you also need to be able to report back to your various stakeholders with what the progress of the project is, and potential ETAs for features that they’re waiting for.
Maximise business value
Backlog prioritisation is all about making sure that the development team is always working on the most important thing that will provide the most business value. You can use a two dimensional matrix to help you with this decision. Think in terms of urgent vs important, and work in the following order.
If a PBI (Product Backlog Item) is urgent and important, work on it 1st
Work on important but nor urgent PBIs next
Then urgent but not important
Finally work on the PBIs that are neither urgent nor important
Since new work will constantly be coming in from feedback and other new ideas, if you follow this rule you will often find that your team almost only works on category 1 and 2 above, meaning you’re never working on unimportant work. Often you’ll find that if a PBI is urgent but not important, it will either no longer be urgent after a little while, or else it will become important.
Think in terms of Minimum Viable Product (MVP)
As a Product Owner, you have to be able to say when a feature is good enough for the team to stop polishing and adding bells and whistles, and instead move on to the next feature down the list.
This is especially important when budgets are tight (i.e. 90% of the time) to make sure that the business gets what it needs before you work on what it wants.
Be aware, however, that there is a slight cost in this, as if you want to come back to it later, you will have to let the developers get re-accustomed to that area of their code.
Manage Technical Debt
Technical debt is code or documentation that builds up over the course of any project, where some parts become legacy or shortcuts that were taken earlier cause headaches for work done later. Even diligent teams often find themselves with a buildup of technical debt as best practices change or new technologies emerge.
The solutions for this are varied, and include re-architecture, adding more measures such as unit tests or automated UI tests, and, most commonly, refactoring. Creating and prioritising these PBIs is one of the hardest things for Product Owners to do, as only the development team really knows extent of technical debt in any project, and often they won’t speak up about it because they caused the issue. See my other post about trust in teams to make sure you get full transparency in this.
My advice is to have a little bit of technical debt reduction in each sprint, as well as in your Definition of Done
Have a vision for the product
As well as taking requirements from others, the Product Owner should be in a very good position to have a holistic overview of the long term goals of the product, and this is known as the Product Vision. Keep this vision in mind as you’re shaping the product, to make sure it’s heading for a good destination.
Motivate and empower the team
There are plenty of ways for a Product Owner to impact the productivity and motivation of a team.
Show gratitude for work well done or particularly useful features delivered
Share the team’s success with others… always giving the credit to the people who did the work
Be available throughout the sprint for clarifications to PBI Acceptance Criteria (i.e. the requirements)
Try not to change your mind on priorities and requirements part way through a sprint as it can ruin the flow of a team that is on a roll
There are five interrelated issues that undermine the performance of a team, and they can be viewed from 2 angles:
The Negative Angle
This is popular because as managers we’re often looking for what’s wrong so we can fix it:
Absence of trust.
If the members of the team do not trust each other, then they cannot be totally honest with each other.
This is the hardest to fix as it’s often personality conflicts or deep-seated issues that cause this, but if you get this part right, the rest normally follows much more easily.
Fear of conflict.
Without trust, people will not have the healthy debates that are necessary to arrive at better thought through decisions.
People who don’t trust each other will not openly say if they have made a mistake, or don’t know something, so you can’t get to the heart of any matter discussed. They are also less likely to proffer an idea if they might know another approach but are not 100% sure in case of looking silly.
Lack of commitment. If the team has not aligned behind a decision, then the individual members who did not agree with the final decision will ultimately be less committed to that decision. This will lead to the bare minimum being done by that person, and a lot more micromanagement needed to get the desired result, which is a waste of good team minds and management effort.
Avoidance of accountability.
If an individual is not committed to the course of action, then they are less likely to feel accountable (or hold other people accountable).
Another way of thinking of this is taking ownership. If they are not committed and don’t take ownership of a task, they’re much less likely to hold themselves and others accountable for successful delivery.
Inattention to results. Consequently, they are less likely to care about the group results (and instead focus on achieving their own goals).
I have found these principles so useful that I have printed this summary and I have it on my wall at work, both to remind me, and to help explain to others where team breakdown problems are likely originating.
The Positive Angle
Sometimes it’s also good to look at these from a positive side, so as a manager you know what you’re aiming for in your teams. These are the pillars that underlie exceptional teamwork:
Trust and vulnerability
When team-mates trust each other, they are not afraid to be vulnerable in front of each other, and will admit mistakes or shortcomings, allowing their team-mates to help fill any gaps.
Healthy debate
One of the main pillars of teamwork is healthy debates, where each team-mate feels empowered to contribute, ideas can be shared, and plans formulated.
Part of this is each team member being able to let go of any ego and talk about the topics from an objective viewpoint, which is why team trust is so necessary.
Commitment to decisions
The outcome of the spirited debates should be a decision on a plan forward, and since each team-mate felt empowered to contribute to the plan, they should then also fully commit to the agreed decision.
Accountability
With everyone fully committed to the plan, they should then be comfortable to be held accountable (and hold each other accountable) to the KPIs.
Attention to results
If the group has a shared feeling of success, they will all strive for the same results, and will pay attention to if those results are met.