RSS
 

Lost your way with Agile?

25 Feb

“People don’t change, their priorities do”
- Unknown

Coaching is an interesting journey. For a coaching engagement that stays the course, it can often take both coach and coachee to very unexpected positive outcomes and places. However, there are also many cases where coachees don’t follow through with their own processes and end the coaching engagement. One very common reason for this is that the change required (which the coachee thought they wanted in the first place) is too hard, or to use a coaching maxim: the current situation did not hurt enough for the change to happen.

When coaching we work from a number of fundamental premises. One centers around the premise that the coach/coachee relationship needs to be voluntary on both sides and some pairings don’t work well together, so the relationship ends and hopefully the coachee finds a coach they can work with.

Another fundamental premise reads: If someone does not want to change from their current state (or is not truly ready to change at that point in time), no amount of coaching can make them change. At some stage the engagement ends.  Sometimes coachees go away for a while and return when they are ready for change and end up seeing the coaching engagement through. Many coachees however never return, the change they are hoping to make is too hard for them to accept.

I find a similar phenomenon inside organisations attempting to transition to Agile, and must confess that for me it is one of the hardest things to deal with as an Agile coach.

Organisation X hears about Agile, and decides to implement it. They get everyone on training in “doing” Agile, and then get going with it. Very soon they start struggling with some aspects of “doing” Agile, and decide to call in an Agile coach. When the Agile coach arrives, he or she starts to suggest changes, facilitate alternative thinking and ideas to approach these problems, and then the organisation ends up rejecting these ideas, stating that Agile does not work for them.

Interestingly, the latest Chaos report lists “Executive support” as the first factor in the list of factors needed for Agile to be successful. Using that as a platform to start from, perhaps the Agile coach should first determine the appetite for this level of support among the executives of the organisation.

So, here are some real coaching questions for these organisations (it is also useful for organisations who are successful in their Agile journey to constantly consider these as well):

  • Why are you adopting Agile, what is the underlying business reason, how will you know when the desired end-state has been reached?
  • As an organisation, why would you say you want help, and then act (and react) in ways rejecting the help given/offered, what aspects of change could be so disruptive that you are not prepared to make them, even to get the benefits of Agile adoption?
  • And, why would you want to blame Agile instead of looking for the real reasons why your organization is struggling with change or not getting the results you hoped for?
  • If your organisation was serious enough to invest in starting with Agile, why is it not serious enough about seeing through the consequences of the initial decision and investment?
  • If the initial commitment to Agile was serious enough to invest in, what has changed inside the organisation to negate this commitment?
  • Are there any competing initiatives in the organisation that may dilute the appetite for the agile adoption/ transformation?

If you find the organisation thrashing and changing direction about the Agile adoption then it can be good to return to the original reasons as to why this journey was started. You will need to determine if these are still valid. If you find the original reasons (or vision) is not valid any more, then it is time to re-assess before you continue.

Another phenomenon I have seen is that organisations expect immediate results or a higher level of Agile maturity right from the start. The quest to Agile maturity remains a journey, no matter how good your people are. The truth of the matter is that it takes time to build high performing Agile teams, and many organisations keep forgetting this months into an Agile adoption initiative, resulting in disillusionment.

Many leading Agilists, blogs and publications talk about “doing” Agile as being simple, but “being” Agile as being very hard. Along this line, I must confess that it remains difficult for teams and organisations to keep this vision alive if they are stuck knee-deep in confrontational daily standups, missed sprint commitments, general toxic political faction battles and diverging organizational visions.

If you are currently struggling with adopting Agile, or have adopted it, but are struggling to get it right, perhaps you need to see if your priorities changed as an organization; As with the quote at the start of this article, changed priorities will impact your maturity in Agile.

 
2 Comments

Posted in Agile

 

The Agile Alliance: A Q&A with Board member Shane Hastie

21 Feb

2016 marks the fifth and final year SoftEd’s Shane Hastie will be on the Board of the Agile Alliance.  We talk to Shane about the growth of the Agile Alliance over the past five years and the direction of Agile in the future.

For those that don’t know, what is the Agile Alliance?

The Agile Alliance is a non-profit organisation which was founded by the authors of the Agile Manifesto after the original meeting in which they identified the values and principles of agile software development. Subsequent to drafting the Manifesto the Agile Alliance was formed as a vehicle to share knowledge of what agile development means and help spread the ideas through the software industry.

The mission statement of the Alliance is:

We support those who explore and apply Agile principles and practices to make the software industry productive, humane, and sustainable.”

The primary activities of the Alliance are related to collecting and disseminating knowledge about all things Agile.  The most visible of the activities has been the Agile 20XX conferences which run every year in North America.  (Agile 2016 will be held in Atlanta, GA 25-29 July).   These conferences bring over 2400 people together from all around the globe, exploring what it means to be Agile in all aspects of their work.

In addition to the annual conference the Alliance supports and runs other events, such as the upcoming Agile Alliance Technical Conference and the OnAgile virtual conference (the next OnAgile conference will be held later this year – watch the Alliance website for details as they become available).

The Alliance is brand-agnostic – we support all who align with the thinking embodied in the Manifesto, irrespective of the label or specific approach they adhere to.  Scrum, Kanban, Scrumban, eXtreme Programming, DSDM, Lean Startup, LeanUX and many more approaches fall under the “big tent” of the Agile Alliance.

In addition to running conferences the Alliance collects and shares content about Agile approaches, making it available through the resources section of the website.

The Alliance supports many events, conferences, meetup and local user groups around the world.  The website contains an up to date list of these events, and communities.

A lot of the work of the Alliance is carried out by volunteers through initiatives – any member can propose an initiative and there is a shepherding process whereby initiatives are evaluated against the values of the Alliance and funding is allocated to support the mission.  These initiatives cover a wide range of activities, from providing funding to user groups to being speakers from out of town (Speaker Reimbursement)  to helping new community conferences get established (Conference Sponsorship) to training facilitators to teach high-school students skills needed to be successful in the modern world, using Agile ideas as the basis (Five Saturdays), and many more.

How long have you been part of the Board?  What is your role/the Board’s role?

I was elected to the Board in 2011, and re-elected in 2013.  My term ends at the end of this year, by which time I will have been on the board for five years.   I was the Secretary of the board in 2015 and again this year.

The Board of the Alliance is responsible for setting policy and direction for the organisation.  We set the strategic direction and approve funding for the various initiatives and staff activities of the Alliance.

One of my personal goals for being on the Board was to help change the organisation to have a more global focus.  Historically the Alliance was perceived as being very North America-centric.  In the five years I have been on the board we have seen a clear shift to a more global focus, with initiatives being undertaken in multiple countries and board membership with wide geographic distribution.  This year there are more people on the board from outside the USA than those based in the USA.

One way we have exposed the internationalisation drive has been through the location of our board meetings.  We hold at least one board meeting per year outside of North America, and part of the decision about where to hold a meeting is the opportunity to engage with the local agile community.  Last year we had a meeting in Wellington (and we held an Open Space event for the local community where we had over 100 people come together for a fantastic day.

Last week we had our meeting in San Juan, Costa Rica and we had an event with the local Agile community, which was very well attended and supported.

We supported the community in Brazil in their formation of a local Agile Alliance of Brazil, with a focus on the Agile Brazil conferences, and we are currently forming an Agile Alliance of New Zealand to help unite and share Agile knowledge across the various communities.

The Alliance has a number of staff who do a fantastic job on the day to day work of the Alliance.  They look after such things as correspondence and engagement with the membership, the conference logistics, seeking sponsors and corporate members, marketing, maintaining the website, curating the website content and the general administration that’s needed by a not for profit organisation.

A number of board members are also engaged in Initiatives as volunteers; our roles as volunteers are distinct from our board membership.

In my volunteer capacity I have been directly involved with two initiatives:

  • The Agile Extension to the Business Analysis Body of Knowledge™ – this is a joint venture with the IIBA, a team of volunteers wrote the content for the Agile Extension, which has become a much used reference for business analysis in Agile environments.   There is a new initiative just starting to revise the extension to incorporate the latest thinking around Agile analysis.
  • The Agile Manifesto Translation – the goal of this initiative is to have the Manifesto translated into as many languages as possible, and to use the translation as an opportunity to build local Agile communities.  The idea is to have a team of native speakers collaborate on translating the manifesto into their own language, discussing and conveying the underlying meaning of the values and principles in the resultant translation, rather than simply doing a mechanistic translation.  So far the Manifesto has been translated into 58 languages – you can see them here (scroll down past the first page to see the languages listed).  The status of all the translations completed or under way can be found here.  My role is to support the translation teams and administer the wiki which contains the translations.

 

Why is the Agile Alliance so important for the progression of all things Agile?

Because the Alliance is the “big tent” we provide a place for different ideas to meld together and for the best elements of all the different Agile approaches to combine and evolve.  We are not tied to a single brand or model, and we actively encourage the evolution of Agile thinking through the events we run, the initiatives we support and through making the knowledge available to the global community.

The conferences and community events provide a wealth of knowledge, exploring what it means to be Agile, exposing new ideas and techniques to the scrutiny of the community and making the content available to the wider global community through the resources pages on the website and by supporting a wide range of events around the world, along with the support for the global Agile communities.

The Alliance strives to hold the space for Agile thinking in all its various forms and implementations, staying true to the ideas embodied in the Manifesto, and providing a forum for new ideas to emerge and be shared around the globe, free of commercial influence and bias.

 

What is the most pervasive trend in Agile at the moment?

There are a few things I see at the moment.

  • First is the steady progression of Agile thinking into areas outside of information technology and software development.  Organisations are recognising that the collaborative, creating thinking approach embodied in the Manifesto actually apply quite well to areas of the business outside of IT.  Anywhere where the focus is on creative problem solving rather than simply following a predefined process is an area where Agile ideas can be applied.
  • Within IT there is a strong push back to craftsmanship.  The Manifesto emphasises the importance of technical skills and high quality in the work we do (“Continuous attention to technical excellence and good design enhances agility”) and we’re seeing a lot of emphasis on the strong technical practices as teams and organisations realise how important the technical underpinnings are to the products we build.
  • The third trend is what I’m calling the “second wave” of Agile adoptions – over the last 15 years many companies have adopted Agile in their IT departments, often in name only without embracing the cultural change that is necessary to attain the benefits that are possible from an Agile transformation.  Many of these half-hearted adoptions have failed, and the reputation of Agile has been tarnished as a result.    Lately there are a number of organisations taking another look, this time with a clearer understanding about what is actually needed to be successful and with a real desire to make the cultural changes which will result in successful implementation, and real benefits for their people, their customers and their bottom lines.

 

What is the biggest issue facing organisations going Agile?

Adopting an Agile way of working is hard – it often requires that organisations let go of practices, procedures and attitudes which made them successful in the past.  At its core Agile is a way of thinking that requires in a highly collaborative culture where people are recognised as the ultimate source of value and human creativity is needed to solve the hard problems facing the organisations.  We live in a world of VUCA (volatility, uncertainty, complexity and uncertainty) – in this world we need new solutions and new ways of working, what made us successful in the past will actually prevent us from doing so in the future, we need to embrace agility in all its aspects and drive change in our workplaces.

The key to success is “being Agile”, not doing Agile. Doing Agile is about practices,  processes and tools; being Agile is about the important aspects from the Manifesto – individuals and interactions, working solutions, customer collaboration and responding to change. These things require a new approach to teamwork and often significant change to organisational culture.

 

How has Agile changed in the time you’ve been a member of the Agile Alliance?

At its core the values and principles of the Agile Manifesto have not changed, but I see massive change in the practices and techniques, as well as a renewed emphasis on the people aspects of Agile adoption.

Agile thinking has spread around the globe, and these ideas have found fertile soil wherever they have landed. The processes and practices will differ from place to place and organisation to organisation, but the underlying mindset resonates with people in every culture and every society.

New ideas are constantly evolving, agility requires that we constantly learn. What we teach about Agile good practices today is different to what we taught 2,3,5 or 10 years ago. New methods, new techniques are emerging all the time.

Over my time on the Board we’ve seen changes in the Alliance as well – the board has shifted from a working Board to a policy Board, the Alliance’s financial position is strong and we have been able to engage more staff to deliver on the working aspects, this has resulted in more consistent and stable flow of work, new initiatives get supported by a dedicated staff who truly care about the wellbeing of the global software development community.

My fellow board members have been inspirational, being part of such a well gelled team is a wonderful experience and I’ve been privileged to work with a group of courageous and passionate people who truly do live the values.  We don’t always agree on everything, in fact some of our most effective decisions have been made when we have started out disagreeing on a topic because we are able to safely explore all aspects of the decision options in respectful and passionate debate.

 

What role does SoftEd play in the movement towards the Agile mindset?

I’m proud to say that SoftEd has been part of the Agile movement from the very beginning. We hosted conferences in the early 2000’s where we brought many of the founders of the Agile movement out to New Zealand and Australia, we have been a corporate member of the Agile Alliance since 2003, and we’ve taught classes on Agile techniques since 2002.

Our classes have evolved along with the growth and understanding of Agile, we remain brand-agnostic to this day. We teach about Scrum, Kanban, eXtreme Programming, Adaptive Software Development, business agility and many other ideas.

Our courses cover the whole breadth of practices needed to be effective in adopting an Agile way of thinking and working, and our team of Agile practitioners are far more than just teachers of tools and techniques.  We strive to embody the Agile mindset in our interactions with our customers all around the world, going beyond just teaching a class to be trusted advisors, able to help identify approaches which will work most effectively in the customers’ specific environments.  There is no “one size fits all” Agile recipe and we work closely with our customers to help them attain real agility, and the benefits which flow from it.

Helping our customers make their organisations productive, humane and sustainable.

 

 

 
 

The future of testing

15 Feb

“Meteorites, extinction, the end is nigh…Colin Garlick recently posted a blog entitled ’The Impending Extinction of Testers, it was a blog that was provocative (and intentionally so) to get us all thinking about test automation and the future of testing.

Having been in the testing field for almost 18 years I’d say that most of my value added work for various organisations hasn’t been and is not easily automatable. Dare I call myself a ‘sapient’, intelligent, creative human being whose key contributions have been derived from the grey matter between my ears and a combination of using my powers of persuasion, risk analysis, test analysis and design, sales (as in continuously selling the value and importance of testing), prioritisation, exploration, conversation, mapping, drawing, suggesting alternative design solutions, solving complex problems, challenging and verifying assumptions, questioning, lateral thinking, reviewing, being a soundboard, counselling, mentoring, coaching, sharing a drink with the team, and for having a realistic understanding of what might annoy or please the various stakeholders involved (understanding usability, reliability, performance and security concerns that may not be well understood by project stakeholders) among other ‘skills’ – writing short sentences is obviously not one of them.

In that 18 years I have used plenty of automation – but only to help me achieve my goals and to make my work less of a burden on myself and the rest of the project team– test and defect management tools, static testing tools, excel macros, SQL querying tools, test execution tools, test design tools, exploratory testing tools etc. – the main thing is that I’ve been in control of the tools and not vice versa.

I have also been in the awful position of having to run the same suite of tests again and again to check for regression – hours upon hours of monotony and repetition is not my idea of fun nor is it particularly motivating – if there are tools that can help me get some of that work done then hallelujah. Then there’s set up and generation of data, set up and configuring test environments, reporting on progress – I could do with some automated assistance here too.

I really don’t think the manual tester will die out – I don’t think Colin really meant that either – but the use of test automation in its many guises is becoming more and more prolific – and if these tools can help us spend time on ‘higher value’ work then we should welcome that. I suppose it would be much more helpful if we were more open to the benefits of test automation and be less fearful of it.

 
4 Comments

Posted in Testing

 

What does “Value” mean to a Business Analyst?

14 Feb

By Suzanne Robertson & James Robertson, The Atlantic Systems Guild 

As a Business Analyst
I can contribute analytical and systems thinking
So that the eventual solution provides business value by exactly matching the real needs of the business. 

This Business Analyst’s story raises some interesting questions about value, and why the BA is the person to discover it.

Wants versus Needs

Let’s start by looking at how requirements usually get started. If you ask Business Stakeholders for their requirements you are likely to hear statements like:
“I want another screen that shows me the manufacturing totals for the day.”
“I want the spreadsheet to show sales for the previous quarter.”
“I want to know how many new employees we have each month.”

Or you get a story like this:
“As the production manager I want a screen to show me the output of each factory, so that I can see the productivity of all our plants.”

In each of these examples the stakeholder is telling you his perceived solution to some unstated need. You don’t know why the stakeholder wants the manufacturing totals for the day; you are not told what the stakeholder will do if he/she can see the sales. Even the rationale given for the production manager’s story does not really explain the reason for the request.

It is only when you know why somebody is asking for something that you are able to provide value. That is, you can provide a solution which matches the real business need, even thought the real need is as yet, unstated. Any solution that does not meet the real need is a waste of resources.

So let’s consider why people ask for solutions, and what you can do to get to the real need.

First, it is quite natural for a human being to ask for a solution that is close to his own tangible reality. If you are planning a journey you are more likely to say, “Let’s catch the 9:30 bus” rather than, “I want to travel from home to work using the means of transportation that will make the journey in time for me to get to the 10:15 meeting”.

The point is that we talk in tangibles rather than in abstractions. A key business analysis skill is to listen to the stakeholders’ requests, and then apply analytical and systems thinking to discover the real need. You do this mainly by asking “why?”

“Why do you need the manufacturing totals for the day?”
“So that I can compare the units manufactured with the units sold”
“And then what will you do?”
“I will adjust the manufacturing cycle for the next week so that it covers the projected sales”

The result of this conversation is that the analyst starts to understand the real business need:
“As a manufacturing manager  I can compare the daily units manufactured with the daily units sold so that I know how much to adjust the manufacturing cycle for the next week to make sure we can fill all our customers’ orders.”

Also please note how much the story is improved by using “I can” instead of “I want”. “I can” points to a need, “I want” suggests a solution.

Providing Business Value
By applying analytical and systems thinking, the business analyst discovers what it is that provides value to the business. While it seems bizarre, stakeholders often do not ask directly for business value. There are a variety of reasons for this:
• Stakeholders think in terms of how things are done now
• They don’t know what is possible
• The silo mentality puts walls around their thinking and prohibits looking outward at the larger picture
• They think in terms of how to do something, rather than what has to be done
• Their thinking is centred on themselves, rather than the overall business

For all of these, the business analyst can (and should) ask why the request is being made. By understanding the reason for a requirement, the BA is in a position to provide a solution that yields real business value.

The analyst also needs to explore other possibilities for business improvement. For example, the analyst should suggest innovative ideas for improving the existing business policy. While the BA does not determine business policy, he/she can make recommendations so that the business stakeholders are able to choose the innovations which will provide the most value.

The analyst needs to ask the stakeholder:
“How valuable will it be if we can provide a solution that comes up with a daily adjusted manufacturing cycle to avoid unfilled orders?”
“How many orders are unfilled now?”
“What are these unfilled orders costing us?”
“Are there any other factors that are causing the orders to be unfilled?”
“Would it help if we can correlate the manufacturing schedule with the supplier materials deliveries?”

These kind of questions indicate that the business analyst is using systems thinking – looking at the whole of the business, and the effect of each part on the others – to find the real needs. It is only by finding the real need that the optimal solution can be built. The optimal solution is the one that matches the real needs, and provides the most business value for its cost.

Discovery of real needs is the responsibility of the business analyst. Choosing the optimal solution is usually the responsibility of the stakeholders. Working together, both parties can ensure that they are providing the maximum business value.

More information

Suzanne Robertson and James Robertson are principals and founders of The Atlantic Systems Guild www.systemsguild.com and joint originators of the Volere requirements process, template, checklists and techniques www.volere.co.uk

 

The Impending Extinction of Testers

11 Jan

If you are a tester, there is a meteor heading your way, and that meteor is called automation.  Your very survival will depend on your ability to adapt to life with automation.  Fail to make that adjustment and you will join the dinosaurs in the museum as the new exhibit, “apatosaurus tento”, “The Non-Technical Tester”.

Testers who do not embrace this brave new world of automation run an increasing risk of being down-sized, right-sized, or whatever other euphemism you prefer to use for being made redundant.

What is the driver of this doom and gloom?  Cost!  The desire to get more bang for your buck.

A team of (for example) five testers that spends their time writing test scripts and then following those test scripts against a system is in the unenviable position of joining that species on the edge of extinction.

As the manager of that team, I would retain one member of the species to write the test scripts and analyse and interpret the results, but down-size (use your preferred euphemism here) the remaining four members.  Why would I pay for five testers when the simple act of following a test script can be performed by almost any semi-skilled labour at a significantly lower cost?  Especially if I can send that job off-shore to countries where the labour cost is cheaper.  After all, following a script does not require any special training, skills, or knowledge.

To those four former testers, welcome to the fate of the genus apatosaurus tento.  To the surviving tester, be afraid, be very very afraid.  That meteor is putting the remainder of your career at risk as you compete with all the other survivors for the dwindling resources of jobs available for that endangered species, the non-technical tester.

How then to survive this extinction level event?  Don’t just try to survive alongside test automation, ignoring it or hiding from it – that path simply delays the inexorable slide to extinction.  Instead, adapt and evolve!

The tester that embraces test automation has the adaptation that allows them to rise above their former colleagues and feast on the more bountiful lake of bugs available to those who are freed from the time-consuming shackles of manually following test scripts.

The tester that can automate the repetitive and mindless job of following test scripts will find that they have more time on their hands, time that can be spent on tasks that cannot be automated, such as exploratory testing.  Such techniques yield a richer crop of bugs that are not typically found by more mundane testing techniques, but rather are normally found by users in production.  When that happens, the users get angry because there is a roadblock preventing them continuing with their work, and the development team (including the testers) lose face.

As a manager, I would want testers who can offer that bit extra beyond their colleagues, who can find those more elusive bugs, who yield better productivity because they automate all the repetitive tasks that they can.  These technical testers are the ones who will survive the extinction level event of automation.  Welcome to the future of testing, to the evolution of testers into the new species of “homo tento”.

 
17 Comments

Posted in Testing

 

New course for 2016: Agile Test Automation

11 Jan

In 2016, SoftEd launches a brand new Agile Test Automation program.  We talk with SoftEd trainer, Colin Garlick about all things automation.

How has this course changed?

This course provides more hands-on training on the techniques of test automation and the use of some of the most popular tools.  These techniques are put into the wider context of the testing process, including why you would use test automation and what benefits you will achieve by doing so.

What skills can people expect to develop from completing this course?

As well as understanding the concepts and rationale of test automation, our goal is to equip people with the skills (and confidence) to be able to:

  • discover the state of a system from a continuous integration server;
  • retrieve the latest version of the system from the source code repository;
  • run the automated tests of the system, including the unit tests written by the developers;
  • create and run automated acceptance tests using tools like Selenium, Cucumber, and SoapUI.

Why is automation becoming increasingly important?

As I wrote in my blog “The Impending Extinction of Testers”, repetitive tasks like following a test script can be carried out by others at a lower cost.  The real value of a tester is going to be in areas like exploratory testing.  Often testers have not had time to spare in this way, but after automating the more repetitive tasks, they will have more time available which can be directed to these high-value activities.

This course teaches Acceptance Test Driven Development and Behaviour Driven Development, why is this range so important for testers?

These techniques are the proverbial fence at the top of the cliff – quality assurance as opposed to quality control.  Performing acceptance testing after the code has been written (while still important) is the ambulance at the bottom of the cliff.  It allows us to verify that the developers have the correct understanding of what is required, but only after the fact.  How much more efficient could the team be if we could ensure a correct understanding of the requirements before the developers write a line of code?

This is where ATDD (Acceptance Test Driven Development) and BDD (Behaviour Driven Development) fit in.  By defining the acceptance tests first (with the whole team) and using those tests to drive the development work we are practising quality assurance, with the result that the process of running the acceptance tests later (quality control) should be a mere formality to tick the boxes rather than a last-minute discovering of problems.

Click to find out more about the course!

 
 

6 Things the Agile Business Analyst Should Know

11 Jan

There is a lot of confusion about the role of business analysis in agile development – some people say we don’t need analysts, others tell us “analysis is so important we do it all the time”, others say the Product Owner does all the work of analysis, others suggest that business analysts are part of the cross-functional team.

Of course my answer is “it depends”.

Irrespective of the job titles of the roles involved, I agree with Scott Ambler that analysis is so important that we do it all the time.  This means we have to constantly think about the big picture, and the short-range view, explore the meaning behind our user stories and be ready to delve deeper and explain the intent and design of the product we are working on.

So what are some of the important things that I have to understand and possibly do differently if I am working in an agile development team?

1)     Don’t throw the Baby out with the Bathwater

Just because I’m working in an agile team it doesn’t mean that my existing skills and knowledge are now invalidated.  Yes – there will be some things I do differently and some of the documents I used to produce are no longer needed, but a lot of my skills and techniques will still be useful and applicable.

2)     Let go of Ownership and be Comfortable with Sharing

In the “old world” I had a lot of hidden power as the “owner” of the requirements documents.  Whatever I chose to write down would be in the document and would probably find its way into the product. In an agile team I will be responsible for bringing the right people into the workshops and collaborative story identification and elaboration sessions – building stories and elaborating them as part of the development is a team activity, I need to learn to let go and be comfortable in the facilitator rather than arbiter role.

3)     Value Comes Before Everything Else

I have to find and express the value in the user stories, standing up for value over technical expediency and “gee it would be great if…” urges.  Value must be traceable back to the goals, objectives and outcomes of the initiative and aligned with organisation strategy.  This means I need to deeply understand these goals and objectives at every level and advocate for them constantly.

4)     Relationships and More Important than Requirements

I know that most of the requirements identified early in the initiative will change as our understanding evolves I need to be comfortable letting go of a feature or user story, instead focusing on building strong collaborative relationships with the people who have the needs and the people who will work to fulfil those needs.

5)     Flow Matters

Rather than the large batches of work we used to do (build the full requirements document and hand it over to the designers, etc) agile analysis requires us to take a continuous flow perspective – having the big picture in mind and slicing off the small pieces of value as we build the product, slicing and dicing the epics and stories to identify the right pieces of value just in time.

6 Governance Matters

Just because we’re in an agile project doesn’t mean we can disregard organisational governance – there is (normally) a valid reason behind those governance rules which we sometimes rail against.  Compliance and audit are not our enemies, they represent a part of the business that have legitimate needs we need to meet and protect.  Find out what the underlying reason for that compliance report is, then figure out how to meet it with the least cost in time and effort, cultivate allies and get them involved in defining DONE so everyone understands what must be part of the working solution.

There’s lots more to this topic and I’d love to talk to you about it – come along to the Agile Business Analyst class and we will delve deeply into the topics together.

 
 

Bring Agile Beyond IT

06 Dec

In the nearly fifteen years since the Agile Manifesto was written, agile software development has slowly and steadily become the most prevalent approach to building software. The values and principles of the agile manifesto have been an inspiration to software development teams across a multitude of industries. The practices and techniques that align with these values and principles have resulted in better project outcomes, higher customer satisfaction, more engaged team members and higher quality products.

So, in software development we are definitely getting the benefit of these modern approaches to product development.  What about the non-IT areas of our businesses, do these ideas also apply in marketing, or finance, what about customer service?  The reality is that yes, agile ideas can and do work in almost every area of our organisations today.  Forbes magazine calls Agile the “The Best-Kept Management Secret on the Planet” and talks about how organisations that adopt agile thinking are achieving benefits such as improved time to market and increased customer satisfaction (customer delight!) with their products and services.  Harvard Business Review encourages us to “Bring Agile to the Whole Organization” and talks about the changes that will be needed to embrace an adaptive, responsive, creative way of working.

At SoftEd we have worked with many organisations helping them bring agile thinking and practices into their way of working, mainly in the information technology areas but more and more frequently we are working with teams outside of IT helping them adapt the ideas to their specific context.  This has included insurance and banking product design, medical device prototyping, people engagement & talent management, finance and accounting, building hardware devices, business process improvement and even radio crystal cutting.

What all these areas have in common is the reliance on human creativity and innovation for success – they are knowledge worker areas of the business and they face tough problems, ones in which the solution is not clear and simple, rather solving the problems they face requires lateral thinking, ingenuity and collaboration between people with different skillsets.  This is where the commonality with software development lies – the types of problem are similar, so it is possibly to apply the same type of thinking that has been successful in software development to tackle the challenges faced in other areas of the organisation.

Let’s start with the Agile Manifesto – the founding statement and set of guiding principles of the agile software development movement.  The value statement from the manifesto reads:

Manifesto for Agile software development

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools,

Working software over comprehensive documentation,

Customer collaboration over contract negotiation,

Responding to change over following a plan.

That is, while we value the items on the right, we value the items on the left more.

So, how can we adapt this to apply outside of software development – what would the impact be of a small change, replacing “software” with “solutions” – how does it read then?

Manifesto for Agile solution development

We are uncovering better ways of developing

solutions by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools,

Working solutions over comprehensive documentation,

Customer collaboration over contract negotiation,

Responding to change over following a plan.

That is, while we value the items on the right, we value the items on the left more.

 

This feels fine – as someone working in pretty much any area of a business I can buy in to these values and feel comfortable about working in ways that align with these statements.

The social, technical, political and business environment today is in a state of VUCA – Volatility, Uncertainty, Complexity and Ambiguity.

“A rapidly evolving, dynamic, chaotic complex business environment is the norm rather than the exception” - David Sypnieski

 

 

 

 

 

 
To cope in a VUCA world our ways of working have to adapt, decisions need to be made faster, we need to be constantly learning new things, getting feedback quickly from the marketplace and acting on what we learn.  We need to be able to respond to the change around us faster than the rate at which the change is happening.  This requires that we adopt new ways of thinking about work and turn many of our traditional management practices on their heads.

Decision making needs to be as close to the point of customer engagement as possible – this means empowering people to make decisions and not requiring them to go through many layers of management approval before acting.  This also means we have to ensure that the people who interact with our customers truly understand the organisation’s goals and objectives, that their decisions are in line with the intent and strategy of the organisation.  Management must be able to articulate goals and strategy clearly and consistently so that it becomes a beacon which guides actions all across the value stream.

Our employment processes need to change – the skills and capabilities needed in today’s workplaces are different to what made us successful in the past.  The emphasis needs to be on collaboration, problem solving, teamwork and creativity – what Richard Sheridan (author of Joy, Inc) calls “kindergarten skills”.  Technical skill and knowledge is necessary, but not sufficient.  Because the way we do work is changing so fast, the ability to learn is one of the most important characteristics we need to employ for today.  We need to change our reward structures, instead of forcing people to compete against each other we need to have incentive systems that reward collaborative behaviours and are related to the outcome of their work, not the activities they perform.

Our approach to funding and financing initiatives has to undergo a radical rethink.  In a complex, uncertain environment it is impossible to allocate funding 12 months in advance – we don’t know what opportunities are opening up tomorrow, we have no idea how the competitive landscape will change in the next three months, yet we ask managers to identify their budget needs 12 to 18 months in advance, and then penalise them for guessing wrong.  In his HBR article Jeff Gothelf says

“Unpredictable levels of complexity, market turmoil, and shifts in customer behaviour put any product roadmap longer than four to six weeks at a high risk of quickly becoming an outdated artefact”.

Ideas such as Beyond Budgeting have shown that taking a completely different approach can result in much higher return on investment as initiatives get funded for the value they produce, and are constantly revaluated as they deliver incrementally.

The Stoos Network presents a credible alternate approach to management that is based on creating healthy, productive workplaces, rebuilding trust in business and creating better outcomes for all through approaches such as

  • Shared value built into decision making
  • Highly networked, decentralized decision making
  • Recycle, reuse, renew resources
  • Partner with Community
  • Ask Nature. Learn innovative technologies.

Our organisations need to become learning centres, rapidly responding to the new realities and adapting processes, practices, products and our people in response to the feedback we get from within and outside.  Taking a Kai Zen (change for good) approach to exploring what we can improve, what we can discard, what we should change in every aspect of our business.

Futurist and author Alvin Toffler puts it succinctly:

“The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn.”

Our organisations and the people in them need to become adept at learning, unlearning and relearning.

 

 
 

BA top trends

18 Nov

We caught up with Jenny Saunders, SoftEd’s Practice Lead for Business Analysis to talk key trends, hot topics and the future of Business Analysis.

1. What’s the most pervasive trend in the BA space at the moment?

The most important is User Centred Design or Design Thinking.  UCD promotes five key steps: 1. Empathize; 2. Define; 3. Ideate; 4. Prototype; and 5. Test.  It’s all about understanding your customer through persona’s, user groups, observation etc. and then testing to see if your design solution meets their requirements.

2. What do you perceive to be the biggest issue facing organisations at the moment?

The need for speed is the biggest issue but this is coupled with risk aversion for many government organisations as they have to show they’ve spent the tax payers’ dollars wisely.  So in a nutshell – faster, better and cheaper!

3. The role of the BA is changing, how do you see the profession shifting?

I think the need for analysis skills is growing; does that mean that everyone will be called a Business Analyst? Maybe not, but you will see a great demand for analysis skills. I believe that BAs will move out of technology teams and start to work closer with the business, hence supporting the trend of customer driven development approaches.

We need to remember that not all solutions are technology solutions and I think that the world is starting to be smarter about delivering the “right” solution to the “real” problem. A business analyst will ensure that they uncover the real problem (or opportunity) and deliver the right solution, based on the constraints of the organisation.

4. What does the new BABOK® v3 mean for BA’s?

The knowledge areas have changed slightly and are more realistic in their grouping but the biggest change is the perspectives and the simplicity of the core concept model.

Perspectives are used within business analysis work to provide focus to tasks and techniques specific to the context of the initiative. Most initiatives are likely to engage one or more perspectives, and in the BABOK® Guide, they include: Agile; Business Intelligence; Information Technology; Business Architecture; and Business Process Management.

The perspectives provide a real focus on “how” to approach the work due to the lens that you have put on for that piece of work. A great BA will be able to switch these lenses “in and out” at the appropriate time.

6. How will SoftEd’s new Business Architecture course meet the needs of industry?

Firstly I’d like to answer the question “What is business architecture?”

Business architecture provides architectural descriptions and views, referred to as blueprints, to provide a common understanding of the organisation for the purpose of aligning strategic objectives with tactical demands. The discipline of business architecture applies analytical thinking and architectural principles to the enterprise level. A business architect needs to consider the business model, operating model (our processes), organisational structure, constraints and architect solutions that will deliver value to the organisation.

Our course will enable participants to learn a variety of modelling techniques that can be used at the enterprise level but more importantly how to “think and challenge” as a business architect.

 
 

Tips for testers

11 Nov

If you are lucky enough to have specifications to base your testing on there’s always a strong possibility that the author hasn’t captured the requirement as well as they could have.

Can you spot anything wrong with the following statements?

  • March planned for Next August
  • Quarter of a Million Chinese Live on Water
  • Panda Mating Fails; Veterinarian Takes Over
  • Squad Helps Dog Bite Victim
  • Stolen Painting Found by Tree
  • Red Tape Holds up NewBridge
  • New Study of Obesity Looks for Larger Test Group
  • Astronaut Takes Blame for Gas in Spacecraft
  • Kids Make Nutritious Snacks

Even though these amusing statements are not likely to be found in software specifications they do help illustrate the problem of ambiguity.

The following checklist was prepared for the U.S. Air Force a long time ago by MITRE Corporation, but the principles hold true. The authors suggest being on the look out for:

1. Incomplete lists ending with “etc.,” “and/or,” and “TBD.”

2. Vague words and phrases such as “generally,” “normally,” “to the greatest extent,” and “where practicable.”

3. Imprecise verbs such as “supported,” “handled,” “processed,” or “rejected.”

4. Implied certainty, flagged by words such as “always,” “never,” “all,” or “every.”

5. Passive voice, such as “the counter is set.” (By whom or what?)

6. Every pronoun, particularly “it” or “its.” Each should have an explicit and unmistakable reference.

7. Comparatives, such as “earliest,” “latest,” “highest.” Words ending in “or” or “est” should be suspect.

8. Words and phrases that cannot be quantified, such as flexible, modular, achievable, efficient, adequate, accomplish, possible (or possibly), correct (or correctly), minimum required, minimum acceptable, better, higher, faster, less, slower, infrequent, to the extent specified, to the extent required, be compatible, to be associated with.

9 Words and phrases whose meaning can be disputed between developer and customer, such as instantaneous, simultaneous, achievable, finish, degraded, a minimum number of, nominal/normal/average, minimum, steady-state, coincident, adjacent, synchronous.

10. Contractually troublesome phrases:
a. “Design goal.” The developer will spend money and other resources with no guarantee of goal accomplishment.
b. “To the extent practicable.” A decision in the eyes of the developer.
c. “Where applicable.” There are no criteria for judgment.
d. “Shall be considered.” The developer will think about.
e. “A minimum of X.” The developer will provide exactly X.

Most of the difficulty with the fuzzy requirements addressed by the MITRE report arises from the imprecision of the English language as written by most people.

To clarify requirements, the specification author should equations and logical relations to express constraints and computational requirements.

“The system shall do A. After completing A, the system shall do B. After completing B, the system shall do C. After completing C, the system shall do D. Upon completing D, the system shall do E.” If the sequential relationship between tasks A, B, C, D, and E is other than linear, then use a logic diagram: “The system shall perform tasks A, B, C, D, and E as shown in Figure X.”

Finally, a word about the often abused phrase “To Be Determined” or “‘TBD.” TBD is used as a placeholder for requirements that haven’t been finalized. TBDs are meant to be conspicuous and easy to spot. They’re a message to readers that” there’s something missing, but we haven’t forgotten it.” When used that way, TBDs serve a very useful purpose. Specification reviewers who categorically reject specifications containing TBDS are simply inviting developers to submit specifications with much more subtle TBDs which may end up being missed anyway.

I hope this list helps you in your quest to improve the project documentation in your organisation and to find and fix those defects earlier, saving both time and money for the project.


 

 
No Comments

Posted in Testing