For those who were able to watch my first talk back in September 2016 this latest video is iteration 4 of the same subject matter, hopefully becoming more valuable.
For those who were able to watch my first talk back in September 2016 this latest video is iteration 4 of the same subject matter, hopefully becoming more valuable.
My talk last year on Agile success. Linking strategy and vision to objectives and measures of success and how measures can impact behaviours. Behaviour defines culture so getting the right measures of success is crucial.
I recently started thinking about job titles. Working in Agile and the transformation environment means you see a lot of differing titles, each with a given objective and sentiment for the role holder…
Scrum Master – Utilise and teach the benefits of Scrum
Delivery Manager – Agile aswell but please just get things delivered and quickly
Agile PM – Erm get stuff done and be agile about it
The most popular currently seems to be that of an Agile coach. I’ve also got caught up in this craze. Seeing Agile Coach as a promotion from a Delivery Manager or Scrum Master.
I think this was wrong and does the intention and importance of the role a dis service.
Park that for a second.
I also saw a trend 10 years ago in the difference within the unified process between Business Analyst, Systems Analyst and Solutions Architect. At the time Solutions Architect was not a job title it was a project role. So a BA could take on a SA role for a given project. This in theory was alluding to the T shape that we seen in agile. Solutions design and not just a collection of use cases of functional requirements.
Sadly its human nature for us to take everything literally and within a few weeks we were hiring the job title of Solution Architect, this of course unsettled alot of BAs as they saw SA as a promotion.
I also see this now with Agile Coaches, recruiters encouraged to hire Agile Coaches and not Scrum Masters. Scrum Master is also a role and in theory not a job title, a team should choose the framework and processes that make them most efficient so with that said we wouldn’t have a Scrumban Master or a Xanpan coach.
That all said take the agile word away and you are left with a coach, someone who possesses the skill to coach others. Coaching is an extremely powerful skill and has to be taught and refined. I actually do not know very many Agile coaches who have had any real coaching training or experience.
To me this makes for a dangerous misalignment of role expectation and ability. I have worked with some Agile coaches who whilst they live and breath agile and can help teams deliver from a coaching point of view they have destroyed relationships. So the process of doing the work is great but the softer human side is eroded as they lack the expertise and self awareness required.
My feeling is that those with an understanding of agile principles and the ability to work with teams to deliver and continuously improve how the work is done is very different to coaching individuals and teams outside of the context of the actual backlogs. How to be more effective as a group regardless of the domain or product. Some individuals will want this support some will not.
Perhaps question if your delivery focused team based Scrum Masters or Kanban practitioners are part of the digital/IT/product organisation and your coaches are a learning and development function. Coaching is a fantastic investment if supported and delivered effectively. Else it’s an exhausting waste of time for the coach.
Approaches such as Management 3.0 and the thinking behind teal organisations have far reaching implications for organsiations way outside of simple IT delivery. An interesting future lies ahead.
What do you think?
In recent roles I have been much more focused on ensuring the people around me understand the agile values and principles and the benefits they can bring to enjoyment and fulfilment at work.
Agile leads us to talk alot more about the importance of mindset and the belief that if you hire for attitude and train for skill but can you hire for skill and train attitude?
I have had a couple of team members and peers recently whos attitude and behaviour has been brought into question. When speaking with them many techniques are used with the core objective to bring a sense of self awareness. Why are they behaving in a particular way and did they realise the negative impact on others.
Whilst on most occasions this has seen an improvement in behaviour, in the short term at least, we encountered another issue of questionable initiative. Initiative? Where did that come from? Did we test for that in interview? What does it even mean?
We talk about creativity and curiosity which when coupled with initiative are extremely powerful but what affects people’s ability to be perceived as having and using initiative?
I started to realise that there is something much deeper going on. Whilst we can claim that some people just simply lack initiative our upbringing, society and work culture do have a direct impact on how much we are encouraged to use these important attributes.
If we have tight boundaries as we grow up and are not encouraged to try new things and gain some independence then this can have an impact, in society a shift towards a “blame” culture, deferring responsibility and becoming extremely risk averse. In work how much autonomy are we actually afforded to explore new things?
If we are in an environment where instructions are given top down and output is templated and constrained then how can we complain when in given situations individuals do not use initiative? Those full of creativity, curiosity and initiative may have already moved on to find a more suitable environment.
So when you are in a situation where you are questioning someone’s apparent lack of initiative think about how you can help them, understand what might be impacting their ability to use it and encourage them to be more self aware. You might also want to think about how initiative can be given freedom to show itself within group scenarios when interviewing potential new employees.
5 years ago I planted a seed, an Agile Scrum seed at the company where I worked. It took a year to germinate and I actually left the company during that time. I was lucky enough to rejoin to take up the role of a Scrum Master.
The role I left behind was that of a Business Analyst. Like many others I have read all the recommended Agile and Scrum books. They do not speak of the BA role. It becomes very simple, become the PO, become a developer, move into commercial analysis or go to a company not doing agile or doing agile ‘wrong’.
I had the gut feeling that the BA team I so proudly managed would not be required in the new world, I’ve never written this down before and I regret not sharing this view with my team. I protected myself from this fate and moved to another company as a BA whilst I pondered my viewpoint and whether I could leave the profession behind.
8months later I took the decision that the time was right and the opportunity was available to move into Scrum Mastery, I didn’t fancy Product Ownership at that point as I wanted to be able to influence a change in the approach to ‘how’ the work was done not the ‘why’, ‘what’ or ‘when’.
When I returned, my old team had indeed moved out of the new ‘Scrum’ feature teams mostly because they were either seen as ‘waste’ or as a frustrated ‘proxy PO’. They sat all together away from the teams, making up business cases for upcoming work. In hindsight it was almost a necessary growing pain for the whole company. We questioned the value of the role, it evolved into product insight and commercial and financial analysis and they are in a really strong position now as a collective analytics, BI and data science team(s).
The standard role of a BA (interface between the business and IT) is too simplistic and means most agile teams fail to document new/changed logic for the future to make, in particular, operational support easier, to make change in that same area easier and cheaper in the future. To consider not only technical (non functional) but also customer facing considerations.
Agile encourages the T shape of skills and embrace exactly that, ‘skills’. Whilst we may question having one person sitting in the BA position, as we sometimes do with QA or SM. We still need the skills that the role normally brings. We must train the team with those skills even if we make the roles non mandatory. Maybe we should all take the view that we should work to make ourselves redundant, share all our skills and automate as much as we can.
Besides there is always something more interesting to work on 🙂
work to make ourselves redundant, share all our skills and automate as much as we can.
So, fast forward to the present, I have a Scrum team with a BA and a PO, what’s that all about? I no longer see it as an obvious problem but I would advise you to review the team, the skills in that team and the context of the work they are doing. My view now is that you need either role or both roles and occasionally neither.
As businesses ‘go agile’ and they add POs and SMs and if you retain BAs, you will notice that the cost of teams stays quite high, I recently read that on average a traditional Scrum team costs £1million per year. That’s a lot of revenue they need to generate. Thus the risk is quite high.
So why not start with the problem being solved/the objective being set and review the skills you think you need. Build up those skills as required, add people to the team as required. Start everything like a startup, review the potential value in solving the problem or doing the work and be strict on who you need involved. Its really simple, time invested = cost and we must generate more value than the cost.
Inspired by lean we should move the people to the work, so don’t just assign random features and projects to existing scrum teams, question who is best suited to achieve the goal.
It’s harder to manage but will be a better investment for the business as a whole and should hopefully encourage more learning in your teams, higher engagement and better products, always hopefully leading to happier customers.
we should move the people to the work, so don’t just assign random features and projects to existing scrum teams
We are all valuable and teams need a mix of skills, the lesson here is to be very honest about what skills we need, look to train skills within teams and recruit people eager to learn.
We need to move away from the days whereby to start more work we need a new team and that team by default needed 8-10 people. £1million is a lot of money, invest wisely.
[Context: Sat in a meeting room reviewing Scrum Master CVs and interview performance…..]
I’m in the lucky position to be part of a company looking to digitise it’s customer facing and internal systems and processes, striving for better customer satisfaction and efficiency. We have new backers and money to spend and growing a team of talented people.
We are though hitting a lot of the common challenges when working in and around Agile teams. The need for a clearer strategy, linking metrics to the features being delivered and understanding the best way to measure improving team performance.
As part of hiring for a Scrum Master we had the age old debate as to why we need a Scrum Master, it became obvious that those around the teams had done a good job at creating the perception that the teams were working well. However when talking to the teams themselves there remains a number of areas for improvement that the teams need support with.
The complication with Scrum Masters is that typically they command a fairly high salary and often do not add direct tangible value to the software solution.
There are many statements that are banded around that can confuse senior leaders, a Scrum master is there to make themselves redundant, a Scrum Masters success is a reflection of the teams. But what is a ScrumMaster? for most we do not need to defend this too strongly as Scrum Masters come out of the box with Scrum and i’ve been lucky enough that previous Directors understood the value of the role.
Change agents, leaders, mindset enablers and other such visionary statements. However we live in a world where its hard to think long term, we want results today or we might not be in business tomorrow.
I hire only people with Agile experience, so why do I need a ScrumMaster to teach them what they already know?
I’ve lucky enough to have moved through all roles within the software development lifecycle and most recently floated in and out of IT and Business teams and from Scrum Master to Coach to Product Owner.
As a Scrum Master my role was to remove blockers for my team and ensure we delivered. However my own interests (Agile, lean, management3.0, strategy) meant that slowly over time i moved away from the team. It’s human nature for people to be career driven and for budding Scrum Masters this will often mean Seniority and Agile Coaching.
This move from the specifics of the work into the focus on the process and happiness of the team leaves you terribly exposed, if senior leadership do not value the role then, in more difficult circumstances, it leaves you in a difficult position to justify the cost of you.
So……should we hire a ScrumMaster?. I think you really have to question the objectives for the role to ensure you get the right person. In our case we do not simply want someone to facilitate the process, we need our teams focused on some very strict delivery deadlines, someone technically minded who can work between teams and systems. Isn’t that the role of a senior engineer i hear you say? well there are multiple ways to solve every issue and multiple ways to deploy your headcount, this is just our current thinking.
We think we might be looking for a Delivery Manager (popularised by Government Digital Service), i’m even reconsidering my view that that person cannot be the line manager of the team. We need to try and detach personal development through delivering solutions, versus learning and improving skills versus career planning. You can get these from multiple people, its just a case of having the right networks and time permitted for it to be of use.
So that’s decided, no more Scrum Masters for us? maybe, I’m not even certain we should be using Scrum as the outcome we want is fairly certain, but that’s another different conversation.
I’m far more open minded that I used to be, we can make any structure or process work well if we have the right people with the mindset to continuously improve and ideally those that have worked with the more frustrating and inefficient project mgt/software delivery frameworks. Get the right person and the job title doesn’t really matter, as long as the objectives are clear. I’m confident now that I could take on the role(s) of Product Owner, Scrum Master and team line manager and succeed. That’s based on my experience and empathy I have gained by getting it wrong in the past.
So……what about Business Analysts and Product Owners. Life is odd isn’t it, having built a Scrum Master and Coaching team and phased out Scrum Masters in the past, I’m now in a position where I’m prepared to do the opposite.
Essentially, we need to get things done, as quickly and cheaply as possible whilst ensuring high enough quality. We need the teams to be comfortable, inspired with where we are going and know why we are going there. They can decide the path to get there and advise if its not the right destination as we start to travel.
Without wishing to bite the hand that once fed me I’m starting to wonder if all the theory based preaching, the happy clappy, everyone loves everyone and trusts everyone, no need for managers, holocracy, setting each others objectives and salaries etc etc is actually doing the whole Agile movement a dis service, it’s too far from reality in most mature organisations.
Businesses only exist to serve a purpose and make money doing it. If we cannot clearly tie the value of all this hugging to the bottom line then we will lose the faith of the very people that employ us.
HOWEVER, I still see value in embedding the Agile mindset at the more senior level, to ensure the business has agility, could this though be an Agile Coach sitting in the HR/People or L&D team? I’m quite interested in the work Jen D’jelal is doing. If our recruitment teams understand Agile then thats really positive for the future of the business culture and if someone in L&D can train when required then this feels like a great place to be.
Don’t get me wrong I live and breath the Agile values and embody the mindset, however I feel the value much more embedded in project ownership talking about how we are going to increase customer and business focused measures far more than I was getting teams to right their names on balloons.
Why not discuss this further with me……
We hosted the very first lean coffee in Milton Keynes this week and it was a good one.
A great mix of creative agencies, transport systems, automotive, retail and consulting. All with very similar challenges and ideas.
In particular we had some great discussion around the usage and meaning of story points and how on occasion we fail to give visibility and consideration to the business/customer value of the work being delivered and instead only focus on technical complexity.
We discussed Scrum and how in very small teams perhaps adding in all ceremonies becomes an overhead. We started discussing what problems/inefficiencies we were actually looking to solve and that perhaps Scrum wasn’t the most appropriate solution.
Innovation was another that kept us talking for the full 12 minutes (8 + 4), how best to encourage innovation? what strategy encourages the right behaviours? how best to fund? what even is innovation? funnelled through one team or everyones responsibility? continuous improvement or disruption? does your business have agility?
So many questions, perhaps innovation is a great topic for a break out workshop at a conference, if anyone fancies joining me let me know.
Over the last few months I have taken in several conferences, some Agile focused and some more IT focused. Below I have captured the main trends and topics coming out of the community.
My favourite keynote of the year was by Linda Rising: http://www.slideshare.net/AgileSparks/mindset-better-60-min and a youtube video here,
My thinking aligns alot with hers around the ineffectiveness of our approach to teaching and learning through doing and failing.
Below are a few of the main ideas/topics I have learnt from this year…..
Mindfulness – sharing stories of failure in teams to build trust and using time to encourage mindfulness techniques. Makes teams feel safe and relaxed.
Practice mindfulness: https://www.youtube.com/watch?v=thYoV-MCVs0
Management 3.0 and performance mgt – There is growing recognition that the traditional approach to Performance Management e.g. appraisals and reviews are ineffective and especially toxic to Agile teams. How can we experiment with alternatives and be team-centric and more aligned with Agile values. How, with the appropriate support, it is possible and desirable for Performance Management to become a team responsibility.
Jurgen Appelo: Managing for happiness: Don’t manage the people, manage the system around them, as Deming famously said “A bad system beats a good person everytime” https://www.youtube.com/watch?v=hvJ4KlVlqV8
One of the speakers, Adam, works in a team that built: https://www.team-sense.co.uk/home/welcome
Also if you haven’t read this, then I would strongly recommend: http://www.managementexchange.com/story/atlassians-big-experiment-performance-reviews
Ecosystems and platforms – Particularly in the IT community ecosystems are now just as popular as digital, platforms and IoT. Ecosystems are seen as a way to connect with vendors, customers and communities. I still think we are a little confused between platforms, ecosystems and marketplaces and some of these words just feel like a way for a vendor to sell a solution. It’s often interesting to compare and contrast the success of startups versus larger enterprises trying to innovate their business model.
An interesting read from an old boss of mine: https://www.linkedin.com/pulse/mythbusting-platform-economy-mark-ridley
Cryptocurrency – Some really interesting research being carried out by Imperial College London, they built this visualisation of the blockchain showing chains being created live. I don’t pretend to fully understand the underlying tech but it does look pretty. For those that are interested this is the story of how bitcoin was created: http://www.lrb.co.uk/v38/n13/andrew-ohagan/the-satoshi-affair
The internet of things (IoT) –
I’ll just leave you with this: https://www.youtube.com/watch?v=QSIPNhOiMoE
Love it or hate it the world of connected devices is here: https://www.youtube.com/watch?v=lsiHUfIpNGY
Cubic (a little like echo) – https://www.youtube.com/watch?v=SGBSIabp2eg
Accounting for Agile – Where traditional cost and time accounting meets Agile fail fast and iteration and experimentation….starting to recognise that timesheeting individuals and seeing additional work (iteration) as maintenance and not adding new value is perhaps not effective for an agile environment. Measuring individuals output and not teams effects effectiveness. Realisation that timesheets are not accurate, teams are mostly stable so we know how much they cost and we can measure the output and the value generated. We can start to estimate the cost of delivering features as velocity and item size and team size/cost becomes stable (usually 5 sprints). Initial bugs can also be capex and after a period of opex new value within that feature set can then also become capex.
Start to have common sense conversations with your finance teams in the context of value creation. Various methods can be used if estimates are required for spend or a budget can be assigned. Ensure for audit purposes that new features (and feature iteration) and bugs and tech debt etc is clearly defined in the work item tracking system.
This is also interesting talk on Agile accounting and GAAP, capitalizing costs and depreciating investments and how this impacts the bottom line is a growing area of discussion in Agile: https://www.youtube.com/watch?v=wZXG1XON0Pw
Research and cognitive bias – you’re in a bar and looking at the beer options, have a beer (£3) or premium beer (£4). 80% of people go for the premium option. What if we add a third option? A really cheap beer for £1.80. This time 80% purchased the normal beer. By adding an option nobody wanted we changed behaviour.
Kat Matfield always does great talks in this area: https://vimeo.com/148545335
Kata – The technique of kata and kata boards has grown in popularity this year, we had a group present it at our Agile in Covent Garden meetup in February. The background to it is here: http://blog.crisp.se/2013/05/14/jimmyjanlen/improvement-theme-simple-and-practical-toyota-kata. It helps focus behaviour on having a vision, a target condition and regularly experimenting with change towards the target condition. Also the importance of reviewing if you are close enough to the vision (definition of awesome).
Some other interesting related areas are the concept of Gemba (go to the place) and Toyotas A3 thinking: https://www.moresteam.com/lean/a3-report.cfm
Cost of delay – Some interesting discussions about how cost of delay can be used to aid decision making and prioritisation. A few interesting articles:
Urgency profiles: http://blackswanfarming.com/urgency-profiles/ and COD http://www.leadingagile.com/2015/06/an-introduction-to-cost-of-delay/ and if you want to learn from the master: https://www.youtube.com/watch?v=OmU5yIu7vRw
Skills mapping – Something I first heard by Dan North the concept of understanding what skills the business needs versus skills your team has versus what skills your team wants to learn/teach. Rather than dashing for outsourcing or recruitment how can we get the best out of the teams we have. Nothing more amazing than learning something new that I’m interested in and being able to apply it to value creating change for our customers.
Dans talk (Skills mapping diagram at 40minutes) https://www.youtube.com/watch?v=EzWmqlBENMM
FSGD (Frequent Small Good Decoupled) – encapsulated attributes of work should have to be successful. Jon Terry from Leankit talks about the importance of deciding the differing importance between frequency, small, good and decoupled. For them SAAS meant Frequency was critical but not at the expense of quality. They talk about quality in 2 contexts, marketability (from customer perspective) and sustainability (from a technical excellence perspective, keeping customer in the long run i.e. cost, performance).
Technical standards were also introduced TLDR (tested, logged, documented and reviewed)
Youtube video: https://www.youtube.com/watch?v=cHEJ7wIojc4
I hope you will enjoy these topics too, if you want . to discuss any at length let me know 🙂
As a complete aside Schindlers Elevators, had never heard of them but when looking into IoT and connected cities they are trying to innovate. Not only how devices connect to lifts, how marketing can be targeted based on mood (facial detection) but also how elevators can be ordered and customised in a more digital way.