I had a great opportunity recently to attend the Leading SAFe course, led by Dan and Phil at Add Agility.
Here are some of my thoughts about the two-day course, where attendees gain the knowledge necessary to lead a Lean-Agile enterprise by leveraging the Scaled Agile Framework® (SAFe®) and its underlying principles derived from Lean, systems thinking, Agile development, product development flow, and DevOps.
I have been working in and leading agile teams for a number of years, but in more recent months I’ve worked with customers that have decided to adopt SAFe as their framework of choice for conducting multi-team planning.
The course outline states:
Participants in the class gain insights into mastering Business Agility in order to thrive in the competitive market. They discuss how to establish team and technical agility and organise and re-organize around the flow of value. They also learn and practice the skills for supporting and executing PI Planning events and coordinating multiple Agile Release Trains (ARTs). Participants in the class explore the importance of adopting a customer-centric mindset and design thinking approach to agile product delivery. Learners also develop an understanding for implementing a Lean Portfolio Management function in their enterprise.
Things I found:
The course is full on. There is a lot of material to cover (over 400 slides in 2 days) and so make sure you have coffee on tap!
A lot of the course content and principals come from other methodologies. If you have a good grounding in Scrum, XP, Lean etc you’ll do well.
The course seems to be traditionally based around synchronising releases. I think of this like how it must have been to release software versions onto CD-ROMs. If you ‘missed the train’ your feature wasn’t going to customers until they bough the next CD. SAFe have clearly tried to leverage DevOps and push towards more regular releases
Attending the course prepares individuals to take the exam and become a certified SAFe® Agilist (SA) – but not all the content is covered in the course. You should prepare to do some home study in order to complete the exam successfully.
Would I recommend it? Yes. If you’re interested in adding some governance around how you do agile at scale, this course could be really beneficial to you.
Over the past couple of years I have seen a growing trend in BAs and product teams striving to define what ‘success looks like’. It’s comes from a desire within the business to understand how we’ll know when we’ve achieved what we set out to do and what the world will look like at the finish line.
I think it’s worth recognising that there are probably a collection of terms out there that describe similar things here. You may call the, Critical Success Factors in your organisation and have associated KPIs.
If you’re working in a Scrum team you may refer to theses as the Definition of Done, a series of criteria or success factors that must be met in order for something to be considered as completed, as done.
The closest I could find in the BABOK about measuring success was in chapter 6.3 Specify and Model Requirements :
The activity of analysing expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models
I’m a real advocate of this approach and have found it resonates well with the product team I sit in, as together we defining a testable state in which to measure if we have achieved our intended goal. This is similar to the team’s approach in writing software, where they will write tests that fail, prior to writing a line of code. They then write software that passes the tests that were defined. Once all the tests pass the project is finished.
However, too often I think BA’s try and define success far too late in a projects life cycle and as a result, miss out on being able to show real business value early in the process.
Many of you may have heard of Eric Ries and Lean Startup. You may have discredited it as applying to your organisation, as you’re not a startup, but I believe that everyone can use Lean Startup principles in their work, especially business analysts.
Eric discusses in his book, The Lean Startup, a new approach to testing hypothesis to help innovation. I believe we can use this same approach when identifying the impact of problems we uncover in our projects, whether it is a bug, an inefficient process or a missed deadline. And using the same principles we can continual measure for the improvements made as we get to work on tackling those issues.
Measuring failure, the “as is” state
So before we can measure what success looks like I encourage people to re-frame the problem. I ask them what failure looks like, often to their surprise. What I mean is, if we did nothing to resolve this issue what would the cost or impact top the business be. This may cause them to go and collect some information in order to answer this, but chances are they have a good idea and can articulate it.
This is a great place to start and will have many other benefits that can feed your product vision, and even help with ROI calculations further down the line.
Once you understand the problem or opportunity, you can start to consider solutions for achieving your goals, but how will we know that we’ve actually been successful?
If you work for a company that sells products online it may be easy for you to measure success. If you sell more items or increase your profit on what you sell, you’ve clearly been successful and perhaps these are some of the most obvious ways of measuring success and may not require models or equations to prove it.
However, if your project doesn’t have an obvious revenue stream to measure, you may need to be a little more creative with what you measure – and this I think, is where Business Analyst can really take a lead.
Have you ever considered the impact your project may have on customer satisfaction? Do you know what your current customer satisfaction score is and would you know how to measure it? Do you know where you rank amongst competitors, especially the ones that you are chasing for market share? I’m willing to bet someone in your organisation already knows the answer to all of those questions!
Do you know how long a manual process takes to run in your organisation? If you could identify improvements then you could calculate an efficiency saving to the business in terms of employee cost or an increase in productivity per employee.
Now measurement isn’t just something that we do at the end of projects. I often hear of the Definition of Done or the definition of what success looks like as being the finish line of a race that once crossed, means the project is closed. While this is true, I sort of dislike the analogy as it suggests it’s the last thing that happens in a project. I believe measuring success is a continuous process. if the definition of what success looks like is our finish line we measure at every step along the race course asking the question, have we crossed the line? Have we improved revenue, have we improved customer satisfaction? For teams that work on incremental delivery strategies, this data is crucial in checking that the team are going in the right direction and if they’re not this data will help support the need for changing direction or pivoting. This in itself is ensuring project success by getting early visibility of failure and risks.
Change, measure, change, measure…
So I’ve explained how I think measuring should take place at every step of the journey and how “what success looks like” is the finish line, the goal we’re aiming for. But in reality the improvements and gains that we see from the success of our projects don’t end once we cross that finish line. If you’ve managed to see an increase of 2% in sales as a result of your project, that’s for life. The business will continue to see that additional value month on month and as a BA I think it’s important that we shout about success and recognise the value that we as BA’s and the teams we support add to the organisation we live in. Everyone likes to have evidence they can show their boss that the project they’ve delivered was successful… And if it over achieved, how pleased will you be that you were tracking the data from day 1!
So to conclude I want to just recap on what I’ve said and recommend some further reading:
Measuring success is linked right back to your initial requirements and stakeholder desires. You’re helping your team prove that they’ve been met with real data
Measuring success is a continuous process, measuring it at the end is too late… you could be miles off and have not known
Measuring success continuously reduces risk and allows for innovation and agility
Evidence of success is the best reward of all, and will really help you as a BA
Recently I gave a presentation on Agile Estimation, as based on some of the material cover in the course I attended. While I can not take credit for the materials, or the activities, I was keen to write about them as I believe my own perspective could be of benefit to others who find themselves in a similar situation.
Estimation is something that every team does, but approaches vary wildly. Commonly developers will estimate in hours based on their feel for how long a task or activity will take. While this is not terrible the individual doing the estimating makes a number of assumptions about their approach, their experiences of similar tasks, their confidence in finding a solution, the risk involved, etc. However, what if the person that has done the estimate isn’t the person who will complete the task? What if they aren’t aware of the assumptions made and are not able to understand how the estimate was so low or high?
In the session I asked the teams to estimate the distance from our office to Paris. Instantly they started working on understanding the distance, what roads they would need to take, a ferry or a train and if they would need to sleep on the way. Within a very small variance the teams were pretty consistent in the distance it was from our office to Paris. However, when they started to estimate the time required, based on their distance estimate, the hours varied based on speed assumptions, accounting for traffic and other variables.
What I was trying to show the team is that most of us are good at judging the complexity of a task. They were all good at determining the distance, the route and even the car they’d take and those that had driven the route before knew more confidently what the number of miles required to drive.
When teams decouple complexity estimates from duration estimates they are usually more accurate. Even for the guys that had driven to Paris before, the number of miles required to drive was not smaller in any way, the size or complexity of the task didn’t change for them.
Mike Cohn teaches that we should
Estimate size and derive duration
You see duration or velocity is something that a team understands best through practice. Once teams get into a rhythm or cadence they naturally start working more effectively. This will improve the speed that they are working at and the number of tasks that they can complete.
By estimating as a team (or at least in pairs) developers will at least get some peer input into if their estimates to help them check they are in the right sort of range. And through conversation and repeated estimates the teams should see an improved confidence in their estimate ranges.
Last month I attended a fantastic course to become a Certified Scrum Product Owner (CSPO) with the legendary Mike Cohn.
What are Product Owners?
To quote the Scrum Alliance:
“Certified Scrum Product Owners® have been taught the Scrum terminology, practices, and principles that enable them to fulfill the role of Product Owner on a Scrum team. CSPOs are typically the individuals who are closest to the “business side” of the project. They are charged by the organization to “get the product out” and are expected to do the best possible job of satisfying all the stakeholders. CSPOs maintain the product backlog and ensure that everyone knows the priorities.”
The course covered
Overview of Scrum
Scrum is empirical
The Scrum project community
Roles and Responsibilities
Team / ScrumMaster / Product Owner
Your role in the four Scrum meetings
Things that are not your job
Chartering the Project
Creating an “Igniting Purpose”
Estimating the size of work
The Product Backlog
User stories on the product backlog
The product backlog iceberg
User stories in a formal contract
What is potentially shippable?
Changes during the sprint
Sustainable pace & over commitment
The proper level for prioritizing
Four factors to consider
Theme screening and scoring
Extrapolating end dates
Fixed-scope and fixed-price projects
Scaling the Product Owner
Sharing one product backlog
Visualizing a large product backlog
The scrum of scrums meeting
The chief product owner
I loved the course and would highly recommend it. I particularly found the session on Prioritisation one of the most valuable with the section on Kano Analysis being used in my recent presentation. I’ve also taken what I learnt in the Estimating session and delivered something internally with colleagues at Sigma to help the whole team to estimate better.
@JamieClouting Thanks, Jamie. I appreciate you participating this week. Now go order the team around just like I said a PO should do 😉
Last week I was lucky enough to present again at Camp Digital, a two-day event run by Sigma UK full of inspirational seminars and workshops discussing user experience, exploring key trends in our industry and connecting people in our community.
It’s the second year that I’ve been invited to speak, after my presentation last year on Rapid Prototyping.
Minimum Viable Product (MVP) is a key lean startup concept popularised by Eric Ries to maximise validated learning for the least amount of effort expended. No-longer just a concept used in the lean startup world, defining MVPs has become a popular product development strategy for agile teams around the world. But what’s the impact of constantly focusing on delivering the ‘minimum’ and do your users ever truly love your product as a result.
In this session Jamie will look at how your team can develop an MVP that both meets your business requirements and keeps your users coming back for more.
In the next couple of weeks I’ll be presenting at a ‘Lightning Lunch’ at Sigma UK on Kanban and how you can optimise the flow of tiny tasks (stories) to make predictable deliverables. This presentation is based on a blog post I wrote some time ago on the same subject.
I’m currently working on a very large Scrum programme that uses a board very similar to a Kanban board, however, we’re not enforcing WIP limits and we only ship things once a sprint. While this in itself feels very fast and very agile to some, it’s not without risks and sometimes feels a little ‘big bang’ release due to the amount of code that is getting delivered in a single sprint. This got me thinking about the continuous test and deployment cycles within Kanban teams as a potential enhancement to our current process.
Kanban doesn’t pretend to solve the problems, but it does allow teams to focus on continuous delivery and continuous improvement. It encourages teams to work as a multi-disciplinary unit rather than as a collection of silos and functions.
I should say that I have only ever done this ‘agency-side’ and as a result commercial constraints sometimes limit our ability to apply too aggressive WIP limits. I’d be really interested in hearing from anyone who has experience of running Kanban projects for multiple customers within a software/design agency. I’m sure there is some additional tweeks to help the implementation.
This week I heard a fantastic podcast over at TheBACoach.com about writing high value user stories through structured conversations. In it Ellen Gottesdiener and Mary Gorman, authors of Discover to Deliver, suggested collaboratively working on process diagrams with your customers. In fact, they suggested encouraging stakeholders to break the diagrams!
The idea got me pretty excited about a project I’m currently working on and some workshops I had coming up. Although I’m pretty confident at diagramming as a requirements specification technique and have studied UML, BPMN and database modelling techniques, I rarely use them for elicitation purposes. And I have to say, however confident I am with the practice, I’m always worried that a stakeholder will spot the bit I’ve missed or will mention an edge-case that I didn’t identify. But Ellen and Mary were suggesting a completely different approach – hold your hands up and say it’s not finished, that it needs some polish and it needs input to be completed and allow your stakeholders to roll their sleeves up and participate in the drawing of your process diagrams.
So that’s exactly what I did, I thought back to some of my experiences of prototyping wireframes and some of the lessons learnt are very transferable. Mainly, if the prototype looks polished stakeholders will think it’s finished (and will often be far more critical). So, we used paper and pens to draw out a basic process flow, there were no swimlanes or beautiful straight lines that a tool would give you, but it was there, a vehicle for some structured conversation.
I put it on the table with some other pens and watched as the team looked at it, quite shocked at how bare it was (probably questioning my fee…) but straight away people started drawing on the missing elements. And then they took it further, “this bit is only happens if X is true” and “We want to be able to delay a step, in fact we’d like to be able to delay two of the steps.”
We were prototyping a process flow, well they were and I was taking the notes from all the business logic and constraints that were being discussed. And because I wasn’t holding the pen and doing all the work I was able to sit back and facilitate the discussion and prototyping, dipping into the 7 Product Dimensions [pdf], that I also learnt about on the podcast, ensuring that we had covered where the ‘data’ was coming from for an aspect of the diagram or what the ‘control’ was around another.
Now I was lucky, the team I was working with are pretty technical. In fact they are a mix of subject matter experts and other analysts, which made the job a bit easier. But even if your team aren’t expert diagram drawers, with your help they’ll be able to articulate enough to help you draw something that they can validate. Constantly ask questions like:
Is this right?
Is there anything that happens after this step?
Is there anything missing that you can see?
Working with your stakeholders in this way will help them to feel empowered in the delivery of your project, it helps develop rapport between the team and will pay dividends over the lifetime of the project.
I usually try and keep these posts technology agnostic, but when it comes to wireframing it has to be said that I’m an Axure fanboy. I know there are lots of other great tools out there but this is the one that I’ve settled on.
Axure has a built-in specification generator, which reminds me of projects where the quality of my deliverables were measured by the length of the documents. However, I’ve been playing with some of these settings in order to turn the built-in features into something a bit more useful. Here’s what I discovered:
The Annotations Widget
This is the Annotations panel within the Widget Properties Pane (you can open it using ctrl+1). By default it has lots of options, covering a range of needs from the features status, risk, owner and benefit etc. While this is all very useful it can feel a bit overwhelming if you don’t know all that information or feel like you’re duplicating effort by repeating info that is already being captured against your user stories. To help me capture what I need, without writing war and peace, I’ve opted for the following fields:
I use this field to describe what the feature is, nothing fancy. “This is a drop down picker that allows a user to select their timezone”.
This field describes what the user can expect to happen when they interact/click on the feature. “Onclick the user will be presented with a list of timezones to select from. By default ‘GMT London’ should be selected”.
I use this field to describe when the feature will be shown and any edge cases where the design or layout may change. “The first time the user uses the application they should set their timezone. On returning to the application this should already be set and display the option the user has stored previously in their preferences”.
On generating the prototype it builds into HTML and adds a small icon over the top right hand corner of the feature. If you hover over them your cursor will change to have a ‘?’.
When you click on the note it will open up and can be moved around the page, in order to prevent it to obscure the feature it is describing.
You can play around with combinations of fields that you use and even have different ones saved for different clients. Any fields that are left blank when annotating your prototype will not be shown once the HTML is generated.
Sharing Axure Files
If you’ve not seen it yet I strongly recommend Axure Share. It allows you to store and share your Axure prototypes and even has functionality to allow users to discuss elements on the prototype.
If you want to find out more about the Axure annotations feature why not check out the following:
This post is the first in a 2 part series on visualising your product backlog. The second post will look at Story Mapping.
Recently on a trip to Sweden I was introduced to Impact Mapping, sometimes refereed to as effect mapping, as a collaborative work-shopping technique for identifying software features and mapping them back to organisational goals and user personas. The following article is a summary of the technique, as described in the book Impact Mapping: Making a big impact with software products and projects by Gojko Adzic, along with a mix of my own observations from being involved in facilitated Impact Map sessions.
So what is impact mapping?
Well according to Gojko Adzic, an Impact Map is :
A visualisation of scope and underlying assumptionsm create collaboratively by senior technical and business people. It is a mind-map grown during a facilitated discussion
Impact Maps can help you build products and deliver projects that make an impact, not just ship software. Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.
How do I impact map?
Working your way through the following questions with your team or customer will allow you to build up an impact map from scratch. These are often best achieved in a facilitated workshop environment with a number of key stakeholders represented.
Defining the business goals is essential for any project and its the focus of Impact Maps. Why are we doing this? What is the goal that we are trying to achieve above all else?
Goal definition is about understanding the problem, not the solution. It should not be focused on specifically creating a product or application, rather explaining why its existence would be useful. It can be useful to try and tie the goal to the organisations value chain.
Increase online conversions by 15% in the next quarter
Attract 20% more customers in the next financial year
The first branch of an impact map looks at actors. For anyone who has spent some time with UML or traditional use cases you will know that actors can range from end-users and external suppliers to third-party applications or systems. Try and capture decision makers and those able to achieve the goal you defined or aid/block it from being achieved by others.
Consider the following questions at this stage:
Who can produce the desired effect? Who can obstruct it?
Who are the consumers or users of our product?
Who will be impacted by it?
These are the actors who can influence the outcome of your goal.
Students with a tablet device or smart phone in the classroom
Corporate employees with access to the secure drive
The second branch level of an impact map sets the actors in the perspective of our business goal. Don’t list all the activities that an actor might want to take, just the ones that are focused on achieving your goal.
Consider the following questions at this stage:
How should our actors’ behavior change?
How can they help us to achieve the goal?
How can they obstruct or prevent us from succeeding?
These are the impacts that we’re trying to create. Note: They are not product features.
Get faster access to accurate information
Have access to a wider network of colleagues to collaborate with
Once you have answered the goal, who and how questions you can start to consider and define your scope. This is the third branch level of your impact map and starts to identify the top level features of your product.
Consider the following questions at this stage:
What can we do, as an organisation or a delivery team, to support the required impacts?
What is the minimum that you can deliver to achieve your goal
These are the deliverables, software features and organisational activities. Do you not get too detailed at this stage and consider what the shortest route is through your map to the goal. It is very unlikely, and is potentially not a wise investment, to deliver all the features identified in your map.
This is a section that I have added but its a step that I find useful to help understand how a feature will help the organisation to achieve their goals. Agile uses the phrase “Definition of done” and in a similar way I like to think about “What success looks like”.
Consider the following questions at this stage:
How will you know when your goal has been achieved?
What action or level of engagement will signify a success for your feature?
How long will it take to get usable data from this feature?
The outputs from these questions will help formulate your measures or metrics. Where possible you should measure the smallest individual unit Avoid vanity measures, page views and impressions are worthless unless they prove an increase in conversion or engagement from your intended users.
A completed signup form
A social media share
What are the outcomes?
In Adzic’s book he describes deliverables as being features, lines of code that helps organisations in achieving their goals, and of course he is right. However, I’ve often found it’s useful to understand at what point your Impact Map will be ‘finished’ and what the immediate deliverable from the exercise are.
Firstly if you are creating your Impact Map in a workshop then it will be produced within a timebox and will most likely be completed within the one session. Impact Maps are collaborative artifacts and unless you have all your stakeholder representatives available after the workshop, it’s not wise to carry on developing them in isolation.
Secondly, the largest deliverable from me as a business analyst are a prioritised list of features and measures, mapped against their actors (or personas) and goals. This allows you to quickly slice your Impact Map into a product backlog, understanding that what you have is probably high level epics that will require some breaking down into smaller stories.
The diagram above shows how you can map the who, how & what into stories that can be worked up.
What do I need to impact map?
When I first drafted the outline of this post my intention had been to discuss different types of mind-mapping software here. And for the record, I use Xmind and have had some great results with it.
However, having written this post now, it’s clear to me that what you need in order to effectively Impact Map is a good mix of stakeholders who can represent both your organisations goals and your users needs. Without access to them you will not produce an effect map that adds real value and your roadmap and backlog will be flawed from the start.
During a recent job interview I was asked to demonstrate my workshop skills. The company supplied some background about the project and the domain, along with a list of stakeholders that would be present in the workshop. I had 45 minutes to maximise my impact and capture some requirements, show some value add and write up some user stories. I was nervous.
Now this is a scenario I’ve been in 50 or 60 times in my professional career but never had I sat and thought “What is my workshop methodology?”, “What process am I going to follow to ensure requirements are captured systematically and to a high standard?”.
I turned to my trusty Business Analyst Handbook, flicked to the chapter on workshops and to my shock the advice was as follows:
Well the above was useful, but I’d been successfully doing that bit for sometime now, I wanted a bit more.
I settled on some simple areas to focus on, that I felt could easily be reused as a basis for any workshop. They are as follows:
You can use this technique on a whiteboard, flip chart, with different colour post-it notes or index cards.
I prefer using A1 flip chart paper stuck to the wall, laid out as the diagram shows. The reason for this is quite simple, after the workshop you have a physical artefact to store, reference, review in any future workshops or conversations.
Workshop capture screens. Each section represents a single A1 flip chart page.
Like all good business analysts my first thought was about the goal, the value, the vision.
I came up with the following questions:
Why are we doing this project?
What value will it add to our product and to our customer?
What is the vision for this project?
I identified that the Product Owner was probably the best-suited stakeholder to capture this information from and assigned a portion of the workshops time to this activity.
In my experience the sorts of answers that you get in this phase of a workshop are around business need. They often take the form of “We want to drive/increase traffic…”, “We want to increase conversions/revenue…” or “We want to save some money…”.
The next area I focused on what what is being built. This might seem like quite an obvious point but it’s important to capture what your stakeholders are expecting to see built. If you fail to do this you may have stakeholders with falsely set expectation from the very start of the project.
Some of the questions I asked at this stage are:
What are we building?
What functionality is it going to have?
What is it going to look like?
Try and steer clear of any questions that ask about the technical implementation. Some projects will be bound by technology constraints from the outset, but as a BA try and remain as agnostic from the technology being used until you understand Why the project is needed and What is being built, only then can you pick the most appropriate technology.
In this part of the workshop it may be appropriate to draw some process flows or sketch some wireframes of the interface design. I identified that the UX consultant was probably the best stakeholder to capture this information from.
By this stage you should now have a good idea about the project’s vision and the goals that it is attempting to achieve. You should also have a good understanding of what will be implemented during the project. This phase of the workshop gets down to the following:
How are we going to build it? Technology/Platform?
How are we going to resource the project? Internal/External staff
How will we know when the project is finished? Definition of done?
This is the time to discuss technical implementation of the project and any constraints that could be present during project delivery. All stakeholders will have input at this phase but Development/Technical leads and Product owner/managers will probably lead this phase.
Risks & Issues
This section is not a formal phase of the workshop, it’s something that runs in parallel to the previous 3 phases.
Those who have come from a project management background will be used to managing RAID logs. Now I’m not suggesting that as a BA you look to maintain a RAID log but there are often times during a workshop that you will capture feedback or information that needs to be recorded but doesn’t really fit into any of the above areas. These are sometimes non-functional requirements or constraints to the project.
The sorts of things that you will hear during your workshop that could be recorded as a risk or issue
All page loads must happen in under 1 second
The QA team need 4 weeks notice to write test scripts
A project manager has not yet been identified for this project
Workshops are a great tool for facilitating requirements collaboratively. They can be used to both understand a problem and to communicate a solution. By bringing together a range of stakeholders from across the business and delivery team it allows for all parties to be part of the solution. This can have a really positive effect on buy-in and stakeholder ownership of the project, which can only be a benefit.