James Yoxall Process Director
User experience of agile project: I have never known a project to develop at such a rate."
- Job Title
- Process Director
- Bio
Joint founder of IndigoBlue, James is IndigoBlue’s process director and a recognised expert in the Agile community. His work on Dynamic Uncertainty Management and Incremental Strategy has revolutionised the approach to implementation of Agile at scale.
James has over 30 years’ experience in IT delivery. Having begun his career at Logica and worked with numerous global companies including Shell Oil, Deutsche Bank, Reuters and JP Morgan, he has excellent practical knowledge of traditional and Agile project management on large-scale developments (up to £20 million). His roles have included Projects Director, Project Manager and Chief Architect. He first introduced Agile into an organisation in 1999, and has run a number of highly successful enterprise-scale Agile transformation programmes including Specsavers, IFDS and Aviva.
Amongst other speaking engagements, James presented the keynote at the Agile Business Conference 2011 - Delivering Agile in Government; Learning Lessons from the Commercial Sector.
- Short bio
I'm IndigoBlue's Process Director and spend most of my time working for our Agile Programme Management clients and working out how to apply Agile thinking in increasingly more complex situations.
- LinkedIn profile
- http://uk.linkedin.com/pub/james-yoxall/0/59a/678
My Most Recent Posts
Agile Business Change
19 NOV 2012 | Posted in agile business change, uncertainty management | Author James Yoxall |
3 Comments
Agile is now established within the IT industry as a means for delivering more business value faster. However, there is a problem. IT created the concept of Agile (with a capital “A”) and many people therefore see it as an IT delivery process and assume that it does not affect other parts of business change. At the same time, on the IT delivery side, there is frustration because so much more could be achieved “if only the business were more Agile”.
James Yoxall, IndigoBlue Process Director presented a webinar - Agile Governance from the Top Down - as an introduction to the Agile Business Conference 2012 [44:51].
It is generally accepted that stories should be Small. Some teams even demand that "no story should be bigger than a few days". Unfortunately, focusing on Smallness can lead to confusion and reduce the benefits of Agile. This is the third blog in a series which aims to provide a clear and practical set of criteria for good stories.
What's in a Story (Part 2)?
27 APR 2012 | Posted in agile value, incremental process, story | Author James YoxallIn a previous blog I raised some objections to the acronym INVEST, a widely-used definition of what a good story should be. In this post I introduce the alternative acronym that we use: VISIT. More importantly though, I provide a concrete and rigorous definition of a story.
The acronym VISIT stands for:
Agile Business Conference Keynote
13 OCT 2011 | Posted in Agile Business Conference 2011, agile governance, agile principles, incremental delivery, uncertainty management | Author James YoxallI had the privilege of presenting a keynote at the Agile Business Conference last week "Delivering Agile in Government; Learning Lessons from the Commercial Sector", together with Jerrett Myer of the IfG (Institute for Government).
Agile in the Cricket World Cup?
25 MAR 2011 | Posted in agile reporting, project velocity | Author James YoxallWith the cricket world cup in full swing (but with games taking place during the working day) I have discovered that you can get a very accurate picture of the ebb and flow of a game simply by checking the standard graphs.
Somewhat bizarrely, this proved very useful in a conversation with a governance group I am working with when discussing the relative merits of different ways of reporting velocity.
There still seems to be confusion around what exactly a Story is, and how you differentiate between good and bad Stories. There are existing answers out there, but there is still too much vagueness. This is the first post in a series proposing a more definitive answer.
The de facto criteria for stories is the acronym INVEST. When an organisation we are supporting tried to use INVEST though, we found ourselves resorting to phrases like: "it should only be used as a guide". This is an unsatisfactory situation.
So what are the problems with INVEST?
Does Agile Reduce Design?
21 DEC 2010 | Posted in agile engineering, design | Author James YoxallI often hear the complaint that Agile reduces the amount of design possible on a project. The typical scenario cited is that design work has had to be "cut short" because the developers are ready to play the story. I get the image of a nest full of baby birds clamouring for food.
The intent is quote the opposite: Agile should increase the amount of design, but decrease the amount that occurs up-front. This requires a fundamental mindset shift: design is not synonymous with up-front design.
MY RECENT VIDEOS
James Yoxall, IndigoBlue Process Director presented a webinar - Agile Governance from the Top Down - as an introduction to the Agile Business Conference 2012 [44:51].
MY RECENT BLOG POSTS
Agile is now established within the IT industry as a means for delivering more business value faster. However, there is a problem. IT created the concept of Agile (with a capital “A”) and many people therefore see it as an IT delivery process and assume that it does not affect other parts of business change. At the same time, on the IT delivery side, there is frustration because so much more could be achieved “if only the business were more Agile”.
MY RECENT ARTICLES
This paper presents IndigoBlue’s approach to integrating Agile with PRINCE2®. It explains why the two approaches can be used together at a conceptual level, and follows with a discussion of the key differences and how they can be resolved. This paper assumes that the reader has a prior level of knowledge of the two approaches.
It is often supposed that Agile and PRINCE2 conflict directly with each other, and cannot be used effectively together. The basis of this view is that PRINCE2 is ‘process-heavy’, while Agile is ‘process-light’.
