Boost Blog

From good to great product ownership

2017-02-08T01:59:41Z

The Product Owner has arguably the most challenging of the roles in the Scrum process and is often referred to as the ‘single wringable neck’! To learn more about this role and how better to support it as a Scrum Master, I attended the Passionate Product Ownership Workshop with Jeff Patton late last year.

For anyone who is not familiar with Jeff’s work, he is the author of renowned Agile book User Story Mapping. This book takes you on the user’s journey through a product to give you insights into how to build something of value to a user and a client – a process we use here at Boost in kick-off meetings.

The course covered:

the day-to-day roles and responsibilities of a Product Owner and team
working collaboratively with the team to create successful products
various design principles and practices that can support product discovery (how to determine what you need to build and why!)
hands-on experience with product ownership practices to make you feel comfortable giving them a go in your own environment.

One highlight was the importance of learning velocity and making specific goals that speak to learning more about how your users/customers use your product rather than making assumptions. This involves using metrics and data to understand how your customers currently interact with your product, and creating a hypothesis on why this is and how you could improve their experience. This is an approach we’ve been exploring at Boost, and Jeff gave me a deeper understanding of how to implement it.

Another thing that resonated with me was the use of an opportunity canvas to explore potential opportunities with a product. An opportunity canvas begins with identifying problems or solutions, looking at the types of customers you have and the challenges they currently experience with the product (different customers may have different issues so it is best to identify these customers/issues separately) and then exploring how your customers currently deal with the problems you have identified or any work-arounds they may be using to meet their needs. From here, you can work to identify how to solve the problems so that you can move your business forward (as well as fulfill the needs of your customers).

I found this process particularly interesting, and I’d be keen to hear from product owners who’ve tried it.

Contemplating the insights I’ve gleaned from the course, as well as from my experience working alongside Product Owners, I’ve three top tips for transforming a good Product Owner into a great one:

Look at the opportunity canvas as a way to determine both the needs of your customer and the business value in the work.
Involve the team in discovery work. Allow them to experiment and learn alongside you.
Be prepared to minimise the output of work but maximise the outcome. The point is not volume, but the quality and impact of your product.

Boost’s 5 trends for 2017

2016-12-09T04:12:22Z

The team at Boost has polished the crystal ball and compiled 5 top trends to give you a glimpse of what we might expect next year, based on what happened in this one. Understanding these trends will help you stay tuned to your customers’ expectations and capitalise on new opportunities. What do you think will define 2017?

1. Agile is the new black

Many more teams – in technology and across other industries and functions – have adopted an Agile mindset to deliver more value faster. Agile in government is on the rise, although the wheels turn slowly. In 2017, knowledge of Agile will be a job requirement. Organisations will recognise that the right culture and mindset is essential for Agile to be a success.

2. Big data for new insights

Analytics and big data are changing the way companies do business and solve complex problems. We’ll need a get a grip on how to manage and analyse ever-increasing flows of data to get the insights we need to transform our organisations and improve our digital relationships with customers.

3. AR and VR gets real

Augmented reality and virtual reality finally delivered hardware and content to consumers. As the cost falls (fun fact: your iPhone 6 would have cost 5 trillion dollars in 1984, and it would not have been portable), adoption will rise, revolutionising the way we interact with software. Next year, movie and TV studios – with professional sports at the leading edge – will deliver new experiments in AR and VR storytelling, as well as an inevitable slew of marketing tie-ins.

4. Machines and humans working together

Machine learning and artificial intelligence will make great strides in 2017. No one will be surprised when you speak to your devices. There will continue to be ups and downs, just as there has been this year (think Amazon’s Echo and IBM’s Watson, and then Microsoft’s AI Twitter bot) as technology companies push the envelope.

5. 5 billion customers

In late 2015, Google predicted the world’s online population would double by 2020 to 5 billion, leading to a tremendous period of growth for the technology sector. We’ve already reached 3.5 billion people accessing the internet – here’s a live counter that makes for strangely compelling viewing …

The art of the retrospective

2016-11-17T22:37:59Z

Retrospectives – regular meetings where the team reflects on and reviews its practices, tuning and adjusting accordingly – are one of the most important Agile ceremonies, yet over time they can deteriorate into repetitive, uninspiring sessions that deliver little real improvement to the way a team works.

We know that retrospectives should drive continuous improvement in the team and are essential for giving everybody a voice at the table. How can we make this happen every sprint?

Running great retrospectives is only possible if you have an Agile mindset. A superficial adoption of Agile ceremonies and artefacts doesn’t cut it. There’s no one way to deal with the all the challenges that arise in projects, and having an Agile mindset ensures you will adapt to changing business needs and deliver value all the time.

Boost’s approach to retrospectives is an example of our Agile mindset.

We keep retrospectives fresh and valuable by varying them according to the needs of the team and the project – we don’t run with the same structure every sprint. Because our coaches are intimately involved with each project team, they identify fit-for-purpose techniques and methods for each retrospective. There are a huge range of activities that can be incorporated in to a retrospective based on the current situation, each helping the team to approach a problem from a different angle. If you ask the same questions each time you run a retrospective, you can expect the same answers.

Our retrospectives also have a bias to action so that things actually change in practice to improve the way teams work. If you don’t arrive at goals each retrospective, and ensure those goals are actioned, the value of the retrospective will be lost.

If you have an Agile mindset, your retrospectives won’t be dull and forgettable but will deliver the lift in performance that Agile promises.

Having an Agile mindset means we are constantly inspecting and evolving our practices. Our teams don’t retain current practices for their own sake. For example, how we manage meteors (P1 outages) in future might be different from what we do today (expediting the outage into the Scrum), if the project’s needs dictate a change. If a team’s Scrum board isn’t providing the value it used to, we change it so that interacting with it is meaningful to the team.

We also innovate with new practices that are not part of the formal Agile process but which are very much in the spirit of Agile as practiced at Boost. We hold a developers’ retrospective, a fortnightly session for all of Boost’s developers to share ideas and work together to improve our software craftsmanship, which has produced fascinating goals that have had a real impact on the developers across all our projects. We also regularly get input from the teams as to what motivates them on an intrinsic level, and how Boost can support those motivating factors for them.

A final example reflects our passion for design combined with our understanding of Agile values and principles. We have developed a successful and unique approach to synchronising UX and design with the rhythm of Agile, ensuring design resource is ready when the team needs it while allowing design to respond to developments in the project as it proceeds. This approach has developed over time with a lot of changes being generated from our retrospectives.

We are constantly improving our Agile craft because we understand that Agile is a mindset, not just a methodology.

What can I do next to run great retrospectives?

Get in touch with Gavin to find out about training and coaching options to improve your retrospectives.

Check out these resources:

Cutting-edge app stirs up more business for Streetwise Coffee

2016-11-16T20:56:35Z

Add a touch of new technology to Streetwise Coffee and you create a cartload of new customers, sweeter-than-ever sales figures and a richer customer experience. The data collected along the way? That’s the froth on top!

A director’s desire to do things differently.

Streetwise Coffee was looking for an innovative way to build its customer base and boost sales for its franchisees. Director, Graeme Harris, had an idea for a competition, but wanted a new and engaging way to bring it to life. A revolutionary new technology had caught his eye and he was intrigued to see if it would work for Streetwise. Graeme knew it involved ‘stamping’ smart devices and that it was developed in the USA, but little else. So how could Streetwise take this brand-new technology and use it to create a one-of-a-kind promotion in New Zealand?

Turning a vision into reality.

This is where Boost came in. Graeme approached us, asking for a cutting-edge mobile app and alluding to the new technology he’d discovered. “They got quite excited about it,” Graeme says. “That was good because it confirmed to me that it was quite unique.”

Our first move was to sit down with Graeme to discuss the outcomes he hoped to achieve. Next, we investigated, studied and tested the technology, a process that involved tracking down the company that developed it and finding out its back-end tech specs. Then we began working closely with Graeme to turn his vision into reality.

How the way we work … works.

Everything we do, we do in small steps. First we mapped out how the customer might interact with the app to get an overall idea of how it should work. Then we evaluated Streetwise’s priorities to ensure that the final product would deliver the most business value. With all this in mind, we designed a basic hand-drawn version of the app. And so the development process began …

To us, there’s no substitute for live testing, so we placed our work-in-progress in the hands of the end-user right from the start – to test it in action and learn from the user’s experience. What’s working? What’s not working? We amplified what worked well and eliminated what wasn’t.

“I was really impressed with Boost,” Graeme says. “They were completely down-to-earth, nothing was too much trouble, you could bowl in any time. It felt like they were part of the exercise, rather than a supplier.”

And after 10 weeks of constant refinement? Streetwise Coffee launched its competition via a state-of-the-art app, the first of its kind in Australasia.

And the winner is … Snowshoe Stamp technology.

Using ‘Snowshoe Stamp’ technology, which records transactions on smart devices, the app enabled Streetwise’s baristas to stamp (or tap) a customer’s smartphone each time they bought a coffee, rewarding their purchase with one entry into a prize draw.

The competition ran across 18 locations around New Zealand, and the app collected data on coffee sales and entry statistics, giving Streetwise invaluable insights into customer behaviour. More than a one-off sales promotion, the app served as a powerful tool for strengthening Streetwise’s customer relationships.

A taste of Streetwise Coffee’s success.

The eight-week promotion was hugely successful, with 78% of businesses experiencing significant increases in sales and 67% achieving their best sales figures ever! At the same time, Streetwise hit its goal of acquiring countless more new customers and reached 500,000 views on Facebook. “It was a good PR exercise,” says Graeme, “and it certainly got a lot of attention.”

Better yet, although the competition has ended, sales are still on the up, thanks to the increase in new customers and closer relationships with existing ones. Graeme is pleased with the outcome. Would he recommend Boost to other companies? “Absolutely!”

Blog post by Jennifer Lane.

Using the “Who” process for hiring developers and scrum masters

2016-07-31T23:33:33Z

This blog post by Clarion Coughlan was first published on medium.com.

Hands up if you find hiring one of the most painful parts of your job? Perhaps you’re new to it and you lack confidence; perhaps your existing process isn’t working as well as it should; or perhaps you’re just plain worn out by the sheer volume of applicants you have to screen and interview. Well, I hear you — having experienced all of these things as a line manager and hiring manager.

A new way of hiring

We recently trialled a new process for hiring at Boost based on the book “Who” that gave us greater rigour, speed, confidence and ultimately a higher caliber of job candidates to interview and hire. I thought I would share our experiences with you because I was somewhat surprised by how applicable “Who” is for hiring in tech. At first glance, “Who” seems to be directed at C-level recruitment. Can it be used for developer and scrum master roles? Is it compatible with our Agile values? The answer is, “Yes!”.

How tech companies are hiring currently

I recently spoke to the hiring managers from Wellington’s best known tech companies to find out more about how we hire as an industry.

It’s commonly understood that who you hire is the most important decision you can make as a company. And it’s common practice for hiring activities to be undertaken by the most senior members of your team. Hiring is undoubtedly a big investment.

You may be surprised to learn that we all share similar approaches to hiring, and it looks something like this:

CV screening — Usually conducted by non-technical staff who find technical CVs incredibly difficult to discern.
Casual chat— Usually undertaken by a hiring manager to validate what is said in the CV is true. A quick assessment for cultural fit and technical skilfulness is also made.
Interviews for cultural fit and technical skilfulness — The most promising candidates are invited to in-depth interviews involving senior managers and tech leads lasting some 2–4+ hours.
Team meet & greet — The leading candidate is given a chance to socialise with, and even interviewed by, future team mates.
An offer is made.

What the best hiring managers know

Tech companies globally are currently preoccupied with two concerns in recruitment — the scarcity of talent and lack of diversity in tech.

The hiring managers I met with know that hiring is not an art. And yet we see so many companies approaching it as such. The lack of process resulting from this mindset creates conscious and unconscious bias, which in turn narrows the talent pool.

Great hiring managers know that good process and a data-driven approach is your best bet against bias and pointless interviews. Without it, you risk excluding promising candidates, and wasting time on interviewing people who are not right for the job.

Outstanding hiring managers know to use hiring teams that are themselves diverse, and who are really good at hiring because they are trained to hire for the long-term good of the company.

In my mind, “Who” offers a process that is compatible with addressing these big concerns that we have in tech recruitment.

Let’s get specific about “Who”

Boost largely follows the process set out in “Who: The A Method for Hiring”. Everything referenced below is taken from it. Please note that I have decided to only focus on the interviewing aspects of the process. So I have skipped the way we reference check and sell the role. So I highly suggest that you read “Who” to find out more :-)

Scorecards

At Boost, we decided that we were only interested in hiring people with the right skills, requisite intellect and growth mindset to join us. This is a subtle but vital shift in our approach. I’ve seen companies inadvertently highlight technical skills over other important competencies because they assess this rigorously in structured tech interviews, while using less robust means to determine “cultural fit” — the catch-all for other capabilities.

To do this, we created Scorecards which outlined the mission, outcomes and competencies for the roles. What’s interesting about our Scorecards is what we’ve omitted — specific languages, technologies and methodologies; education and qualifications; and years of experience — criteria I have seen in more traditional job descriptions. Instead we used competencies that very much aligned with our Agile values such as the one for “growth mindset”:

Has a growth mindset — understands that competency is not fixed but is enhanced through dedication and hard work. Demonstrates a love of learning and resilience to adversity that is essential for great accomplishment.

As applications came in for the developer and scrum master roles, and throughout every stage of the hiring process, we assessed them against these Scorecards. The results were somewhat startlingly as we consistently interviewed great people that blew us away!

First interview: Skype screening

If a candidate looked promising against the Scorecard for the role, we invited them to a Skype call. Skype calls are preferred over in-person meetings because most applicants are screened out at this stage. So you don’t want to spend too much time on these. The call is conducted by one hiring manager and takes no more than 30 minutes. During this call, we asked four questions:

What are your career goals?
What are you really good at professionally?
What are you not good at or not interested in doing professionally?
Who were your last five bosses, and how will they each rate your performance on a scale of 1–10 when we talk to them?

After the interview, we screened out everyone that didn’t strongly match the Scorecard.

Second interview: Topgrading

If a candidate looked promising after the initial Skype screening, we invited them to the next stage which is a topgrading interview. It’s best to do this in-person. However, Skype calls work just as well for people who can’t make an on-site meeting. We divided the candidate’s CV into chapters. Each chapter could be a single job, or a group of jobs. The interview was then conducted by two hiring managers and takes about 1.5 hours. We walked the candidate through their career history chronologically — starting with the oldest jobs. And we asked them five questions for each chapter in their career:

What were you hired to do?
What accomplishments are you most proud of?
What were some of the low points during that job?
Who were the people you worked with?
Why did you leave the job?
After the interview, we once again screened out everyone that didn’t strongly match the Scorecard.

Final interview: Technical

If a candidate looked promising after the topgrading interview, we invited them to the final interview, which is a technical interview and deep dive into their skillfulness for the job. Once again, it’s best to do this in-person, on-site.

Prior to the interview, we prepared a challenge for the candidate. For example, we asked potential scrum masters to do a lightning talk on any aspect of Agile. Whatever the challenge, we tried to make it fun and relevant to the role. We also prepared good questions that helped us to fully comprehend the candidate’s technical capabilities. We understood that poor preparation would result in a poor interview where we didn’t learn much.

As with the previous interviews, we screened out everyone that didn’t strongly match the Scorecard.

And in the spirit of continuous improvement, we reviewed the way we conducted our technical interviews, keeping what is working and changing what isn’t working for the next interview.

Who to hire?

Think of the three interviews as a funnel that is wide at the top and narrow at the bottom with less and less candidates flowing through. For example, our recent developer job vacancy generated 72 applications. 16 people were invited to a Skype call, six people progressed to the topgrading interview, three moved onwards to the technical interview, and one developer was finally hired.

We knew who to hire when:

We were 90 percent or more confident that the candidate could get the job done because his or her skills matched the outcomes on our Scorecards.
We were 90 percent or more confident that the candidate would be a good fit because his or her will matched the mission and competencies of the role.

Wait. Are you nuts?

But wait. These questions are so generic and these are very technical roles. How can you possibly discern anything useful from them and hire a great developer or scrum master?

Trust me, you do.

Think of these questions as scaffolding for great conversation. When a candidate responds to, “What accomplishments are you most proud of?”, you need to get curious and excited by asking follow-up questions until you are clear about what that person is really saying. Hiring may not be an art but you do need to learn the art of having a great conversation. And that’s where trained and experienced hiring teams come in. You cannot avoid having a technical conversation about technical roles! So if you do care about specific languages, technologies and methodologies; education and qualifications; and years of experience etc — don’t worry too much: It all gets revealed without it being overemphasised. What is highlighted are other importance competencies which make for a great hire.

Are you nuts? You’ve published your interview questions and process online. People will cheat and trick you!

Funny. We don’t think of interviews as a test where we set traps for people and see which ones they fall into. We see the hiring process as a shared journey. And as hiring managers, we really want to give great candidates a chance to shine. We want to truly collaborate with them throughout the process and have meaningful and honest conversations about whether or not we should work with each other. And that’s what we’ve managed to achieve with the help of “Who”.

How reducing your batch size is proven to radically reduce your costs

2016-06-14T01:43:30Z

Do you work in an organisation struggling to do more with less? We come across many projects where organisations have tossed in additional resources to meet a looming deadline, pinching pennies from elsewhere and creating stress for all, without solving the underlying problem of how to deliver faster, cheaper and better.

If you want to deliver faster, cheaper and better, you need to reduce your batch size.

Working with small batch sizes (a batch is a unit of work that passes from one stage to the next stage in a process) has tremendous impact. It improves flow and lets us deliver quickly and reach project completion earlier.

In software development terms, a traditional process means a team will define all of the project’s requirements first, complete all of the design next and then finish all of the coding before testing.

In contrast, working in small batch sizes means completing, for example, 10% of the design, the development and the testing before moving on to the next 10% of the product’s features.

Why is batch size important?

There are very good reasons why batch size is important.

First up, when we work with small batch sizes, each batch makes it through the full lifecycle quicker than a larger batch does. We get better at doing things we do very often, so when we reduce batch size, we make each step in the process significantly more efficient.

Smaller batch sizes also mean you’ll deliver faster and reach project completion earlier. Since work on a feature isn’t complete until it is successfully running in production and generating feedback from customers, large batch sizes delay that essential feedback.

Batch size can be one of the most difficult things to optimise but it is economically crucial. Numerous studies have proven that larger batch sizes lead to longer cycle and delivery times – and a longer wait to find out if you’ve delivered value to your customer.

Faster, cheaper, better

There’s a bunch of beneficial outcomes that come from working with much smaller batch sizes than traditional processes recommend.

Some of these benefits are:

faster feedback – the sooner you pass on your work, the sooner you’ll know if there’s an error
better feedback – you’ll know earlier on if you’re building the right product, because you’ll get it in front of your customer sooner
greater visibility – bottlenecks and inefficiencies are clearly seen
improved quality – and when quality goes up, efficiency increases and team morale goes up too
less risk of delays and cost overruns – the larger the batch, the more likely you’ve made a mistake in estimating or in doing the work, and the likelihood and impact of these mistakes increases as batch size grows
reduced complexity – you’ll reduce the amount of complexity that has to be dealt with at any one time by the team
improved decision making – it’s easier to make business and technical decisions and recover from mistakes.

All this makes for better economics. Donald G. Reinertsen’s diagram uses testing as an example, and shows the direct links between a smaller batch size (which results in smaller changes, fewer open bugs and faster cycle times) and improved economics.

Smaller batches = greater output

We’ve even got mathematical proof that you should reduce your batch size!

First published in 1954 and proven in 1961, Little’s Law has been used across many industries. At its heart, it deals with queuing systems, which is what coding-oriented projects also have to deal with. Little’s Law means that if you reduce your cycle time by the power of 10, you increase your capacity/production by a power of 10.

Tips for reducing your batch size

What is an ideal batch size, and how do I reduce my current batch size?

Reinsertsen recommends reducing your batch size by 50%. You can’t do much damage in this range, and the damage is reversible. Observe the effects, keep reducing, and stop reducing when total cost stops improving

Batch sizing is very much a horses for courses endeavour. Some large projects might favour a 30 day sprint, but for most of the projects we’re involved in, we’ve found the sweet spot is two weeks.

If you’re using Agile, you should be working with small batches already. (If you’re trying to implement Agile but using the same batch size as a traditional project – that is, 100% – Agile will not work!) However, it’s important to remember these guidelines when you’re setting up your next project:

reduce the timeframe for delivering results
don’t define all your requirements and success criteria in one go
prioritise your product’s features and begin with the smallest amount of work that will still deliver value to your customer
test and release as soon as that work is complete – adopt continuous integration and ensure deployment and testing efforts are ongoing during your project.

The last word goes to Reinertsen and his video: The practical science of batch size. It has all you need to know about batch size – how it works, why it works and what to do next.

Prioritising versus ordering: what is the difference and why does it matter?

2016-03-30T21:11:56Z

Deciding on the most important thing to work on at any given time is not an easy task for a project team, but it is one of the most important decisions that needs to be made, many times over, from the start of a project through to its end.

A few years ago I was tasked with being the Scrum Master on a project that had a huge amount to get through in a short period of time.

There were many perplexing elements to the project, but one of the most perplexing was that the team had prepared around 400 user stories, all written to varying degrees of detail. I would have hoped for scant detail on each, followed by a prioritisation exercise and a couple of sessions to expand on the most valuable stories.

However, we were asked to flesh out, estimate and order all 400 before the first sprint.

We spent three agonising days refining the backlog. I suspected most of this work would be of little use as many things would change as soon as the first sprint was underway.

I also attempted to run a prioritisation exercise, and I learned pretty quickly that the word ‘prioritisation’ was frowned upon, and the term ‘ordering’ was preferred.

But what’s the difference?

Prioritising, in the Agile world, focuses on identifying the business value of each story, doing the most valuable work first, delivering quickly to get feedback and then reprioritising the remaining work based on what we’ve learned.

Ordering is a type of prioritisation, but it’s based on an assumption that we already know everything we need to know about our project. In this case, ordering meant that every story was of equal value because every story absolutely needed to be completed for the project to be considered a success.

I have never come across a project that couldn’t be broken down and prioritised by value. It isn’t always easy, but it is always necessary. Without truly prioritising, the team runs the risk of building features that no one will actually benefit from, and working without any useful feedback on what was delivered earlier in the project.

Assuming everything is equally as valuable is sure to result in both time and budget running out before we deliver the most important benefits to the user.

Have you ever faced a prioritisation challenge? Has someone in your team, or maybe at executive level, advocated for their own pet part of a project over what is really valuable to the customer? Have you disagreed with your colleagues about what should be done first?

Be prepared to make those hard (but ultimately satisfying) decisions, because prioritisation drives your team’s performance and ultimately ensures you deliver value to your customer.

To find out more about prioritisation, come along to our Agile Professional Foundation two-day course with certification.

3 top tips to set up your project for success

2016-02-17T02:41:57Z

Over the last 10 years, I’ve seen the differences between projects that start from a good place and those that don’t. After analysing the patterns, I’ve distilled it down to three critical things that will reduce your risk and give your project the best chance of success.

1. Partner with your developer

There is a traditional mindset that creates a supplier and vendor relationship which feels a bit ‘us versus them’. Your project will only thrive on a WE relationship. At Boost, we prefer to partner with clients on a project from the get-go, forming a strong, collaborative team that works together towards the same goal throughout the duration of the project.

2. Start at the beginning

Having found your partner, you need to go on the whole journey with them and not just dip in and out.

We often get clients coming to us after they’ve made strategic decisions and already have a project fully mapped out, which doesn’t necessarily set it up for success. We aren’t just about the delivery of a project; we specialise in helping clients to learn about what the customer really needs, validate ideas early, and develop and refine the right product that will lift your digital relationships to another level. We get great results that look very different than if we’d just built something directly from a requirements document.

3. Build what your customer values

Project inception is an exciting time when there are seemingly limitless possibilities. It is also a daunting time for the same reasons. You need to listen to your customer and build something that will deliver the outcomes they want.

How do you get that focus? We have been running workshops with clients for years to achieve just that. We use processes and tools that will make sure you build the right product – and nothing more. You won’t spend money on unnecessary software that has been developed because we made too many incorrect assumptions. They say that 80% of users only use 20% of features, so we start by identifying – and more importantly, delivering – that first 20%.

Check out our free workshops on setting up and running great projects!

Mindfulness and Agile – different sides of the same coin?

2016-02-12T00:48:53Z

At face value there would seem to be no connection between Agile and mindfulness. After all, Agile is a project management methodology while mindfulness is a mental state of awareness.

But I really see a lot of cross-over connection between the two disciplines.

When you practice meditation, you’re being mindful. Your mind is going to wander, skip forward to the future and back to the past. But, by being aware of that and pulling your mind back to the present, you can be in the moment. That’s mindfulness.

It is not dissimilar to the role of an Agile coach. A large part of it is not to be a project manager, but to be a facilitator. It’s about being a servant-leader. The way that you are and act needs to be in a way that best serves the team. That particularly means your awareness has to be in the present: actively present and listening openly to what a person is saying.

Being an Agile coach is not about being in charge of a meeting. You’re there to be a sounding board. Sometimes the team doesn’t need me at all – they know what they’re doing. Part of it is that the team knows they can trust you, and that you’ll make the right decisions and vice versa. You can only do that by being present in the moment, not judging and listening openly to what people have to say.

Being an Agile coach is not about being in a controlling position. It is more of a nurturing role. Sometimes that means having to embrace the awkward silence. Now, usually I’m a talker, and I’ll always find something to say. But as an Agile coach you have to allow that awkwardness – so that someone else can come forward with the ideas.

I usually get up early-ish on most mornings, do some yoga and 5-10 minutes of meditation. This gives my day more balance right from the get-go, and being more centred in my personal life allows me to be more balanced at work.

I like to help, encourage and motivate people; I like to see them doing well for themselves. An Agile role fits my personality, and it’s a mindset that is very aligned with me.

Te Papa changes tack to deliver their flagship website

2016-02-12T00:50:22Z

We’re always keen to help our partners deliver better results, and we were delighted to be invited to run a workshop on Agile at the National Digital Forum – a conference on all things digital in the culture and heritage sector.

We’ve worked with a bunch of great organisations and folks in this sector, including Adrian Kingston from Te Papa. Catching up at the conference, we took the opportunity to get Adrian’s reflections on web development processes and shepherding organisational change.

A national museum, a national treasure, a complex online beast

Te Papa, as befits a cultural treasure and collection, doesn’t take changing its website lightly. As both the first impression of Te Papa for many visitors and a gateway to a vast storehouse of knowledge, the website has a lot to deliver.

The national museum has backed Agile to deliver their new website by February 2016. One of the core members of the team tasked to work on the project is Adrian Kingston.

Fourteen years at Te Papa and part of the Collections Information team, Adrian brought Agile to its business practices since returning from a nearly year-long secondment to the DigitalNZ project.

Transparency delivers better results

Te Papa’s decision to use Agile to develop its new website was both a trust and transparency thing, Adrian says. Senior management had seen Agile working successfully in small pockets across the organisation and were now willing to give a bigger project the chance to run with it.

“There’s a lot of goodwill and trust from others,” he says. “There’s genuine interest from people about whether Agile’s the right way to do it.”

He’s noticed increased transparency with Agile.“It’s a very open decision-making process. We’re participating in a fast, collaborative, user-focused development process; we’re doing things impartially and sharing that knowledge.”

Organisational change in increments

Adrian has been at the coalface of bringing the new website to life. It is a complex beast, broken into three components to allow multiple vendors to help deliver the whole project.

Te Papa would probably be the first to admit they weren’t an Agile organisation. Te Papa’s own project team and planning fully run in Agile, alongside a more traditional waterfall governance team – which “again has been a learning thing,” Adrian says.

Part of the new transparency has included an internal blog. The blog has not only demonstrated trust in the project team but served as a way to promote Agile processes to the organisation, as well as the project itself.

An adaptive process that focuses on the customer

“Agile has been useful in the way we’ve been prioritising requirements and adopting a user focus,” he says.

“Instead of being entirely business focused and all about Te Papa itself, we’ve reminded ourselves we aren’t our audience. So we’ve done a lot of user testing, having worked with about 900 users to get the experience and tone right. One of the advantages is that because it is online we get engaged feedback, and we can make informed decisions and adjust things quickly to make sure we’re delivering value to our customers.”

“That’s compared with spending nine months building it and then seeing how it all hangs together at the end.”

Find out more

“Because it is so visible, the project has attracted a lot of interest from other parts of the organisation. People have been watching our stand ups, looking at the whiteboards, asking us how to do Agile.”

Adrian’s been recommending that people pop along to Boost’s free Introduction to Agile workshop to “see what they think.”

“Agile also shows in small ways as a part of daily workflow,” he says. “If people ask, I’ll send them a Kanban Board by pointing them to a link and getting them to print it. There’s a few around the organisation now.”

Clay McGregor gets Agile certified and scores a new career

2016-02-12T00:48:54Z

Clay McGregor is sure that the Agile Professional Foundation course he completed mid year with Boost is one of the reasons he landed an influential role with an international e-learning company.

The project manager has a background in supervising many different types of projects and though he was familiar with Agile philosophy, he had no formal qualifications in it.

He attended Boost’s free Introduction to Agile workshop and then signed on for the two-day Agile Professional Foundation course to gain his certification as an ICAgile Professional.

Support that takes you to the next level

He says the level of support before, during and after the certification course from Boost has been great. “If I’ve ever had a problem, all I’ve had to do is give them a call, and they’ll be back with advice and help,” he says.

One of the best aspects is being able to tap into the knowledge and expertise of Boost’s own people. “It’s about process refinement, improving your own skills, using the wider Agile process to grow yourself,” says Clay.

He also takes advantage of the Agile meet-up world by attending Scrunch – the Scrum Practitioners’ Lunch – hosted monthly by Boost. “We all bring questions, share ideas,” he says. “It’s great – a highlight of my month.”

Agile delivers value

Clay is now an unashamed Agile evangelist. “Agile is such an intuitive, logical way to carry out a project,” says Clay.

“It is collaborative, quick and focuses the leadership function on facilitation; optimising the contribution of the team and driving towards smaller, obtainable goals that are prioritised for best value for our clients right now, not just at the end of the project.”

“Once you’ve been exposed to Agile’s thinking and methodology, you increasingly shake your head at people thinking that Waterfall or other ways of handling a project can be considered a wise use of people and resources.”

Railsn00bs gets a boosted presence

2016-02-12T00:50:24Z

Taylor’s flatmate wanted a different meeting space for the Railsn00bs October meet-up, so Taylor put forward Boost’s office for the gathering and co-hosted the four-hour Saturday afternoon event of 15-30 developers.

There are about 200 people on the meet-up mailing list for Railn00bs. The October session was the eighth meet-up for the group, Taylor’s second as a participant and first as host.

Railsn00bs is for people interested in learning Rails, or programming in general.

There’s a bit of an introduction to Rails at each one, with projects that people can work on posted to ‘The Wall’.

“It’s something that people can work on that they control. If people want to do a personal project and get some help to do it better they can”, he says.

There’s a flexible approach to what is currently a three weekly meeting and interaction, and Taylor hopes to host again at Boost.

“Railn00bs is a bit like Agile. It’s about collaboration, going about things better, not just blindly forging ahead.”

How getting involved led to better outcomes for our client

2015-11-05T21:06:16Z

‘It’s liberating!’ said Diane Pivac, Head of Audience at Ngā Taonga, when we asked her to describe what it’s like to work with Boost. Our 5-step process works to her benefit: she says always knows what’s happening, she can makes changes as she goes, and she has control over how she spends her money.

“It’s so much more satisfying. The more involved I am, the more I understand the project. The process makes me interrogate what I’m doing and why I’m doing it – to think from the user’s perspective.”

What did Diane enjoy most? Stand ups (very short meetings to check on progress and priorities) were the highlight of her day, and they helped build trust and communication across the team.

Great clients produce great results!

Diane is a great client, and her drive to collaborate delivers outstanding results for her customers and fantastic value for her organisation. We were able to deliver more value and less risk for Diane on the Anzac Sights and Sounds website by prioritising her requirements and delivering them in stages.

“Boost’s process means I agree to features as they are built instead of taking delivery at the end of the project, only to find I’m stuck with bits I don’t like or that don’t work as I want them to.”

We broke her project into short cycles of design and development, focusing on solving the highest priority features. With each cycle, we added more and more features, until she confirmed we’d delivered her project outcomes.

More value with less risk

Thanks to our 5-step process, clients get the benefits of:

strategic, creative thinking focused on connecting you with your customers
seeing working software frequently and approving features as they are built
prioritising and even altering their requirements as they see the product take shape
having control over what we build and how their budget is spent.

We’re chuffed to be strengthening Ngā Taonga’s digital relationships and connecting New Zealanders with their audiovisual heritage.

Find out more about how we work >>
Check out Anzac Sights and Sounds >>

Waterfall and why it’s not suitable for software development

2016-02-12T00:50:26Z

The whole controversy over Agile vs waterfall methodology has been covered in countless articles and blog posts. Yet I still spend a lot of time explaining the challenges and reasons why I think running a waterfall approach in software development projects is not a good idea.

In this blog post I will explain a few key challenges. In my next post, I’ll explain how Agile addresses those challenges.

What is the waterfall methodology?

Waterfall is a sequential approach, separating a project in different phases. It originates in manufacturing and was applied to software development projects later on. Used in software development projects, the phases typically look like this:

Every phase in a waterfall project aims to create a certain output or deliverable. Handing over this deliverable from one phase to the next marks a milestone in the project. Different teams or departments are responsible for each stage. The project manager is responsible for making sure that the different teams keep their timelines and the project stays on budget. The primary measure of progress is tracking milestones.

Having worked at a company in Berlin that builds both hardware and software, I’ve come to understand some very important differences between manufacturing and software development that undermine the value of applying a manufacturing methodology to software development projects.

An experienced software architect once said to me: ‘When you build a house, you cannot build the roof first’. That sounds about right for manufacturing – it’s really difficult to change the layout of a house once you’ve built the walls – but it’s not a good analogy for software development because software can be changed and refactored quite easily.

Value and adaptability

In waterfall projects, requirements are gathered in the analysis phase. Requirements are collected and documented in a specification document. The requirements are grouped into must have, should have and nice to have features. After completing the analysis stage, the requirements should remain stable. Once the product is finished, the whole bulk of the value is delivered to the customer.

In reality, most software development projects have to change some of the requirements eventually. In manufacturing, changes are ideally avoided. The whole process is not built to cope with changing requirements. The more the project has progressed, the bigger the effort required to change existing requirements or add requirements that have been missed during analysis.

You often hear people speaking of scope creep. Instead of embracing change and identifying opportunities to add value to a product, project teams will usually try to avoid change and settle with a mediocre product because going back to the analysis phase usually means delaying the whole project.

Specifying requirements up front means a lot of the requirements are based on assumptions. It is difficult to validate those assumptions, since the first builds are not available until late in the development phase. Once the first builds are available, it’s often too late to change requirements without delaying the project substantially. It’s hard to build the “right product” when you cannot validate your assumptions and requirements through working software.

Instead, having a flexible release strategy opens a lot of strategic opportunities, including beating a competitor to the market, being able to release just a new feature, or delaying should have/nice to have features because there is more important work to do.

When it comes to deployment, waterfall methodology works with fixed released dates. The whole project and resource planning revolves around this fixed date. Bringing forward the release date will impact the overall product quality because, thanks to waterfall’s sequential phasing that leaves testing until the end, project managers will be forced to sacrifice testing time.

Risk and visibility

Before kicking off a waterfall project, project managers need to provide a set of documents, such as an overview of all the requirements, a budget plan, a risk register etc. This set of documents is the basis for getting the sign-off from project sponsors.

Project sponsors are mostly interested in the following three pieces of information:

list of features
project schedule (when the features will be ready for delivery)
resources (staff and budget).

Estimating the effort for delivering features that require new, unproven technologies is an imprecise science. Because waterfall projects are broken into separate phases, it’s possible that the development team may discover some severe challenges weeks or even months after the project has kicked off.

Experienced project managers will try to mitigate this risk by talking to subject matter experts, breaking down the features in smaller tasks and making comparisons to past projects. In the end, the whole plan is still based on a lot of assumptions, resulting in many projects failing to deliver on time and overspending their budget.

“On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.” McKinsey survey, 2014

Surprisingly, project sponsors are still willing to approve budget for projects planned on assumptions. This is despite the fact that, if at any point, the project runs out of budget and has to be canceled, there is nothing to show for all that effort.

Another challenge worth mentioning is that testing is not possible until there is a stable build. Quality and security issues or integration problems with existing products are typically discovered very late in the process. Fixing these sorts of issues takes a lot of effort.

Finally, project managers often have a hard time maintaining their organisation’s engagement with their project. Senior management and stakeholders may take a lot of interest during kick-off and towards the final stage, but not so much in between. Since there is nothing to show other then some mock-ups, usually only budget and milestone updates will be reported. As long as they look ok, management stays more or less out of the project, leaving the project without high-level support to remove road blockages or resolve challenges met along the way.

Feel free to share your thoughts by adding a comment, and check back in a few days if you’re interested in my take on how Agile deals with these challenges.

Agile transition – workshopping the roles

2016-02-12T00:48:55Z

When going through an Agile transition, companies face all kinds of challenges. One of the biggest challenges is getting everyone on board and excited about the transition. During the transition at my previous employer in Berlin I talked to many colleagues who raised concerns. I did lots of one-to-one meetings trying to get to the root of it and I figured, that most of them were worried because they didn’t know how being Agile would change their role and responsibilities.

In this blog post, I’d like to share a method a colleague of mine introduced, which helped us to get a reluctant team on board.

In order to help them get a better understanding of the new roles, we started with a brainstorming session to identify the tasks and responsibilities of their current roles. For the sake of simplicity and easier reading, I’ve just added a few tasks per role.

Click image to view full size

The next step was to add a few columns along the top for Agile roles. We asked the team to move the index cards to the right columns without changing the the rows. This helped everyone to get a better understanding about the new roles’ responsibilities.

Click image to view full size

Some of the index cards sparked lengthy discussions so we asked the team to see if they could identify tasks that didn’t add any value. Soon enough they added another column (stop doing) for those tasks.

Click image to view full size

All team members had attended in an Agile workshop previously, so we asked them to add a few new tasks for the new roles. We added an extra row (start doing) and let the team discuss which tasks to add.

Click image to view full size

Going through this exercise didn’t answer all questions, but the team started seeing opportunities instead of being afraid to lose responsibilities. It also helped us as a transition team to bring the discussion to the teams instead of making decisions for them. They were then able to start thinking about suitable candidates for Product Owners and Scrum Masters.

For a successful successful transition it’s important to have someone with change management skills and not only focus on those who welcome change, but also include those who are more reluctant.