The Agile Tribe

Agile is a Fad!

 
Author:  Jonathan ‘Kupe’ Kupersmith
 

Jonathan 'Kupe' Kupersmith

Jonathan “Kupe” Kupersmith is Vice President of Brand Development, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at kupe@b2ttraining.com.
 
(This blog was originally written on the BA Times blog site. It is kindly reproduced here with Kupe’s permission).
 
Agile is the hottest word in our profession these days. Go to any BA or PM conference and there is at least 1 session dedicated to agile. Even if the session does not have agile in it, you’ll hear the agile word over and over. On sites like this one, there are many blogs and articles written about agile. Here is the article that inspired me to write this post, Four Agile Tips to Eliminate Rework in Application Development.
 
 The article lists these four tips which are credited to agile methods.
  1. Collaborate – Involve multiple stakeholders in requirements definition.
  2. Be Lean – Quote from article – “Agile methods teach us that a 400-page document is not required in order for development to begin. In an agile environment, development can start with high-level user stories with perhaps one layer of detail added.”
  3. Iterate – Approach requirements definition in an iterative process.
  4. Visualize – requirements do not have to be written in paragraph form.

I agree 100% with all of these tips not because they are agile tips, but because they are smart practices. Before the Agile Manifesto was developed, I worked on teams that collaborated, were lean, iterated, and visualized. I wrote about this in a blog post last year, My First Agile Project. I would guess you have been doing this for some time too. This is why the word agile is a fad. In the near future we will stop having debates of whether you use agile vs. traditional approaches. We’ll just start doing what is appropriate for projects to drive results.

This spring I saw Scott Ambler speak and he said we don’t need repeatable processes we need repeatable results. What this says to me, is do what is needed to drive results.  Teams need to come together and determine what will work best to give them the best chance to deliver results. This is just smart.

The agile movement shook our community and made us all think about how we were running projects. It made us make sure we are focusing on business value. Don’t push for agile over waterfall, push for what is right for the project. Push for what is right for the business in the short and long term. Even though I think the word agile is a fad, the agile movement is definitely a trend.

All the best,

Kupe

Don’t forget to leave your comments below.

Advertisements
Leave a comment »

Can't see the wood for the trees?

Author: Cara Talbot

Introducing Agile to an organisation, as with any change program, means significant disruption. The way we do things is no longer the same. We no longer have our traditional rulebooks to clearly define what our roles are, how we’re supposed to engage with each other, or how we should go about our work.

This has heightened anxiety to some degree either consciously or unconsciously for almost everyone coming into contact with it. What’s my role now? How am I supposed to know what I should be doing? What if our team fails? What if I fail?

Most have dipped their toes in the water, and have grown in confidence as successes have been achieved. Some have quite radically removed some of the traditional roles altogether and claimed early successes. What risks might have they introduced critics would argue? It’s all a bit too early to tell. Some have turned into what is being coined as ‘Agile Purists’ where they will argue to the death about sticking to process over pragmatism. Perhaps this is because a natural inclination for some might be to seek new (Agile) rulebooks to replace the old; to firm up the ground beneath their feet and feel secure and stable again.

The irony is that debating at this level stunts productivity and can cultivate fear, uncertainty and doubt within their teams by challenging who should be doing what role instead of simply enabling the team to get on with the business of delivery. Teams can lose sight of their end goal.

My observations in attending the recent Agile Australia conference in Melbourne perpetuated this theory. No matter the viewpoint or appetite for risk, discussion threads resulting from the presentations and workshops were often on the following sorts of themes:

  • All design must be done up front/ no upfront design at all; get rid of the Architects!
  • Iteration Managers vs Project Managers. Get rid of the PMs; IMs aren’t really needed!
  • Business Analysts vs Technical Analysts; Subject Matter Experts vs Business Analysts; get rid of the BAs!
  • er… is there anyone left to progress the project?

Of course, there were also the sales pitches about the numerous methods of Agile we should be applying, although Scrum and Kanban seemed to be clear favourites du jour.

Perhaps, it’s a natural evolution of maturing Agile development for organisations. However, there appears to be a tendency to become overly introspective when faced with the challenge of change, rather than focus on what we are trying to achieve by changing. Perhaps we need to reassure people that their base skills are still valid and valued, we just need to work out how and when to apply them to achieve the Agile values of: doing enough to give the best bang for our buck; focussing on delivering benefit to our businesses quickly; being flexible enough to seize opportunities where it is sensible to do so… in other words, projects still need management (albeit there is a heightened, but not new, focus on coaching first, directing second). don’t get mee wrong though we still need to go into design; problems still need analysis; code still needs to be written and tested… and we need to figure out how to do all of this flexibly and collaboratively.

What was most refreshing to me during the conference was to hear the views of Martin Kearns (Agile Practice Lead from Renewtek), Neal Ford (Software Architect from ThoughtWorks) and Nigel Dalton (CIO of Lonely Planet). These three guys appeared to be in the minority in expressing what I feel being Agile is really about –

“…it’s just a guidebook guys, do what works for getting to your end goal.”

With all the Agile methods, tools, techniques and blurring of roles – there are two constants that run commonly between them all – the promotion of genuine collaboration; and of continuous learning. All roles bring value to the way we work. Alistair Cockburn has said: ‘people are highly variable and non-linear’ and as people aren’t software components – it inevitably introduces variability into projects. What’s great about Agile is that it fits process to people, not the other way around. Agile brings a different approach to process: the team is responsible for choosing their own processes, and as such no project will be the same, and no team will be the same.

We need to avoid the trap of holding ourselves up for too long by trying to figure out who does what activity within the project; and instead lift our eyes towards the project’s end goal. What are individual’s expertise – let them get on with it, don’t shuffle activities for shuffling’s sake. What are the team weaknesses? Get the team to collaborate on how to best address any gaps. Don’t introduce any unnecessary complexity. Think – what will success look like, and how can the team best work together to get there?

For those that are still seeking the new rulebook: http://www.Dictionary.com defines Agile as:

  1. Quick and well-coordinated in movement; lithe.
  2. Active; lively.
  3. Marked by an ability to think quickly; mentally acute or aware.

To me, this means that to be truly Agile you have to be agile! The minute you think you’ve got it right, you’re making mistakes. Agile is ever evolving, and what we see as Agile today is likely to bear little resemblance to what it will look like Tomorrow.

1 Comment »

The Tribe has spoken …It’s (fr)agile…

Author: André Harvey

Extending to Susan’s recent post, “Agile is not the holy grail!”, I’d like to add to the provocation by suggesting that ‘change’ is the Holy Grail and momentum is key; and critical to unlocking the benefit and to mitigating the fragility of a change movement is to know the Whys and What Fors.

For those who are personally, or though their organisation, embarking on an Agile methodology change movement – be it adoption, re-acquaintance or the velvet glove of a performance push ask yourself a couple of questions:

  • Do you understand why you use Agile and what the benefits of Agile are?
  • Could you explain it to your mum?

These are important questions. If you don’t get it, how will you become a catalyst for change? An Agile advocate? Change movements are fragile and need your help.

frag•ile
adj.

  1. Easily broken, damaged, or destroyed; frail.
  2. Lacking physical or emotional strength; delicate.
  3. Lacking substance; tenuous or flimsy: a fragile claim to fame.

Teale Shapcott gets it – for her it’s about usability. No point in building the world’s best ‘thing-a-mijig’ if it’s horrible to use. If your staff and colleagues don’t like using it, what type of customer experience do you think will transpire?

Real world example of the above:

I recently opened an account for my daughter at one of the major banks. A seemingly simple request – I thought. It took 2 hours! The entire time all I heard was how poor the system (read: technology) is and how the users experience is worse – no mention of the customer! Perfect example of an implementation performed in isolation of its users and with little OR no thought for its end-customers.

This is where Agile kills its competition – iterations, prototypes, tangible and timely improvements. To market faster with expectations met and the value of the customer experience in top of mind. Even my mum understands the commercial significance of beating competitors to market.

Mark Palmer also gets it – Based on his post – Agile as a Fundraising Tool about workshop facilitation outside the software development environment. It’s a way of thinking and acting. Anyone who can get ~40 people to work through, short-list and agree on 5 key ideas in an hour is worth his weight in gold (Gold bugs take note – resources will boom!). The fact that he’s taken an Agile concept and broadened its application to rugby in a non-corporate setting is advocacy beyond expectation. It takes courage to suggest and commitment to follow through. NOTE: The Agile Academy should sign this man up for a coaching role!

Seek out those that don’t understand…and then listen, Don’t preach.

Humans have been blessed with a physical design that all but encourages you to listen first, then speak: two ears and one mouth. The least we could do is use our human design in its correct ratio.

In my experience there will undoubtedly be and will always remain some resistance to change. This is a good thing. Creative tension so to speak. It keeps us on our toes. Makes us hone our stories.

A constant reminder of change’s fragility. Seek out the resistance. Understand why it is is isn’t happening. As Susan’s post indicated – it might be justified.

This is where Fiona’s earlier blog post on Leadership is magic, whilst not strictly Agile related, which is refreshing, it’s a nice pointer for when you get stuck with a problem or face an explanation that needs more weight behind it – seek to understand first, then find help.

A behavioural science interjection – in a recent McKinsey article, a case study was performed on interactions with customers via call centres. Whereby, if the call had a bad news element the operator would bring it [bad news] forward to the beginning of the call. In doing so, the operator was then able to coach the customer through the news, in turn giving the customer a sense of control of the outcome and improving customer satisfaction.

What I’m suggesting is something very similar for our colleagues that don’t understand the subtleties of Agile or any change movement for that matter.

  • Seek them out.
  • Then coach, don’t preach.
  • Give back control but take the lead.
  • Give your advocacy stories purpose and meaning – make it an fragile claim to fame.
  • Ps. Final Food for thought – Imagine Pixar without story boards.

Leave a comment »

Are two heads better than one?

Authors: Alexandra Hooper and Tammy White

During the graduate program and in permanent positions, we have worked on several projects and are still puzzled by the way in which Business Analysts and Developers are resourced. One thing we have noticed is how pair programming is used as a standard practice amongst developers but not by other disciplines (for example, Business Analysts), particularly given the obvious advantages that pair programming provides in the developer ‘world’, like:

  1. Improved quality
  2. Reduced cost of development
  3. Learning and training
  4. Overcoming difficult problems
  5. Improved morale
  6. Decreased management risk
  7. Increased discipline and better time management
  8. Resilient flow
  9. Fewer interruptions.

With such benefits we wondered why more often than not, is only a single Business Analyst assigned to a project or stream especially within a large program of work? Surely many of the same benefits that developers experience could be achieved through a Business Analyst partnership/BA pairing. So why is this technique not used in the Business Analyst ‘world’?

At a Business Analyst team discussion recently a comment was made around the variation of skillsets amongst the Business Analysts in the room. Each person had different business experiences and knowledge of tools to offer, which could have led to a truly complementary partnership.

So this made us ponder a couple of questions.

  • Can we really expect a single Business Analyst to understand and facilitate the use of all analytical tools on a range of projects?
  • Why stop at pair programming with developers, why not expand such an effective practice across other disciplines on a project like to business analysts?

In summary, are two heads better than one?

8 Comments »

Is there a role for BAs on Agile projects?

Author: Harshal Pol (http://in.linkedin.com/in/harshalpol)

I think BAs have a major role in Agile projects. Because a BA’s role is more about objectives than requirements. Agile methodology is usually adopted when requirements are not clear or are changing frequently. However, in such cases the basic objectives and priorities are set in the beginning itself. This is where BAs play a critical role. They drive requirements for series of scrums based on these objectives and priorities.

Moreover when the team is busy concentrating on scrum level requirements, BAs help by having control over entire application and integrated functionality of the application(s). Though team/project leaders are there for this task, in practical scenarios, most of their concentration goes into meeting deadlines and completing requirements for the scrum which doesn’t allow them to look at the overall picture. And, also BAs can see this picture more easily then those people as they have better idea of what business demands as a function.

Leave a comment »