Category: Technology

Organisations which have executed an Agile Transformation are often disappointed with the results. They typically adopt the Scrum Framework and create cross-functional teams with all the skills required to do the job. 

Agile coaches and Scrum Masters outline the three pillars of Scrum, Transparency, Inspection and Adaption, and help everyone understand the various Scrum events, such as the Sprint, the Daily Scrum, Sprint Planning, Sprint Review and Sprint Retrospective. 

The teams are mentored on the importance of continuous improvement and it is explained to them that each Scrum ceremony is an opportunity to Inspect and Adapt. 

Despite all of these efforts, the delivery of business value seems to take much longer than expected and the organisation is not reaping the rewards or promises of the Agile Transformation.

The Scrum + CI/CD + Test Automation Combination

It is important to point out that Scrum is a management framework. It does not outline software engineering practices. A software organisation needs to combine the Scrum framework with software engineering best practices in order to achieve high performance.

This leads to a critical point regarding Agile Software Development. The team can only Inspect and Adapt in the Daily Scrum if they receive feedback regarding the previous day’s work. This is where Continuous Integration and Continuous Delivery, CI/CD, and DevOps come into the picture. 

As outlined in The DevOps Handbook, DevOps is based upon three principles: 

1. The principles of Flow 
2. The principles of Feedback 
3. The principles of Continual Learning

The basic idea of CI/CD is to automate test cases as part of User Story development and include these test cases in the CI/CD pipeline. This enables fast and reliable delivery of all future software updates by executing fully automated testing of all updates. In other words, we fully automate the path to production and remove the need for manual approval and bureaucracy. This greatly improves the flow of business value from the development team to production and also reduces the feedback time.

No Continuous Integration or Continuous Delivery

The diagram below shows what happens within an organisation lacking CI/CD. This organisation is inherently anti-Agile as it places zero trust in the people who do the work. 

There is extensive bureaucracy and approval required at every stage of the software delivery cycle. 

Over time the code delivery process takes longer and longer as extra layers of approval are added. This labyrinth of bureaucracy is stifling to the creativity of development teams. 

Eventually, organisations face the stark realisation that engaging in the delivery process is only worth the effort when delivering a large update. Tragically, this is the exact opposite of the regular delivery of small software updates which Agile promotes. 

Typically organisations that work in this way struggle to retain the best employees and are extremely slow to deliver value to customers, even for small software changes.

CI but no CD

The next example outlines an organisation which has implemented a CI pipeline, but still suffers from the black hole of Manual testing and approval processes. 

I state black hole as it is a good analogy for what happens to software delivery. Any business value/software entering the black hole will be very lucky to escape and achieve delivery in the end product or service. 

Ultimately, this organisation still suffers severely from the lack of a Continuous Delivery pipeline and finds it very difficult to deliver value to Customers.

Full CI/CD Pipeline

The final example shows a simplified CI/CD pipeline which facilitates: 

1. the fast flow of business value/software from the developer to the end product, 
2. the fast feedback from automated testing performed in the pipeline to the developer,
3. a culture of learning, as fast flow and fast feedback provide the environment to support experimentation. 

Ideally, the complete pipeline would be as short as possible in terms of execution time. A pipeline which takes longer than 24 hours will negatively impact on team performance as the opportunity to Inspect and Adapt will be delayed. 

Any issues due to the new software will result in a visible failure somewhere along the pipeline and automatically prevents delivery of the software. This allows the developer to perform rapid code changes and get super fast feedback. 

Testing should be shifted left as much as possible within the pipeline. This means that the testing should occur as early as technically possible. This is done for two reasons. Firstly, it enables the fastest possible feedback in case of a failure. Secondly, the execution time of test cases generally increases along the pipeline from left to right and the Deployments used become larger. For that reason, these scarce resources should only be used if all earlier stages of testing have passed.

But we already do all that!

At the time of writing this blog, the DevOps movement, which includes CI/CD and Test automation, has become standard across the software industry. 

This has led to a new and strange phenomenon by which organisations often genuinely believe they have a full CI/CD pipeline, but in reality, they have only implemented the CI pipeline with no CD or only partial CD. 

One product component may have a full CI/CD pipeline while another component only has a CI pipeline. As you can probably guess, the product component with a CI/CD pipeline is typically of a higher quality and supports fast delivery of new features, bug fixes and code refactoring, while the product component with only a CI pipeline typically has quality issues and is difficult to update.

Summary – why continuous integration is important for agile

Agile is built on the expectation that developers can deliver small incremental updates to a product or service. In practice, this will only be achieved if an organisation has put the time and effort into developing and maintaining a CI/CD Pipeline for their products and services. 

Anything less will result in extensive delays and a lack of Agility.

By James Langan
Agile Practices Manager | Ammeon

References 

1. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. Authors: Gene Kim, Patrick Debois, John Willis, Jez Humble.

Discover the Benefits of Agile

Our large team of Agile experts have a wealth of experience guiding critical transformation projects in some of the most challenging sectors. We will provide you with a unique insight into how your people, processes and technology can work together for positive change.

Learn more about Ammeon’s Agile Services

The HR congress was on this week, I couldn’t attend but once again AgileHR was on everyone’s lips. In my last blog, I spoke about how adapting Agile concepts to HR can bring about some significant changes in the productivity and engagement of HR organisations. It sounds like Agile is great but why are more people not adopting it?  Having spoken to some of my colleagues in the HR community it seems that the difficulty in adopting agile is in three parts:

1. The Language of Agile
   Because of its origins in Software development, the language of HR can seem inaccessible to non-technical people. It refers to scrums, retros, ceremonies and sprints. It’s a lot to get through to even begin to understand what it means for teams
2. Fear of change
   Having met with a number of HR colleagues either in training, in forums or in conferences its clear that as a discipline we have a habit of hiding behind convention and compliance in order to keep things going as they are. One of the reasons for this is that many HR organisations hold fast to the Ulrich Model of HR, the 4 roles etc. But guess what? That model was built in 1995! Guess what else happened in 1995. Amazon sold its first book; Netscape the first commercial web browser; We were still 10 years away from the iPhone!  Look how much the world has changed since then and we are still relying on a decades-old methodology for HR. Let’s evolve!
3. Where to start
   HR folk by necessity are both smart and determined. So even if they wade through all the language it’s hard to know where to start.

With that in mind, I am going to give you a jargon-free kick start to Agile which you can start using today. I am going to look at two primary concepts which will help you get off the ground one is about silos in and around HR and the second is the importance of a brief daily meeting.

Tear down the walls

The first thing to do is to break down as many silos as you can. One of the big issues found in software development was that software was being developed in one area and “thrown over the wall” to be tested. The testers had no idea what the code was how it worked and were expected to make sure it worked after a quick handover at the end of the development process. Since the advent of Agile and more recently DevSecOps, Developers, Testers, Security and Operations cocreate software products and solutions with everyone being involved throughout the process to ensure everyone knows what’s going on. Clearly, the same involvement is important in HR functions. A common silo exists between HR and recruitment with recruited candidates being “thrown over the wall” to HR to onboard sometimes with little knowledge of who the candidates are.  

My recommendation

HR and recruitment (and in my teams, I pull in admin) work more closely together to ensure joined-up thinking and action in day to day activities. Not only does this lead to better candidate experience and better onboarding but a broader understanding of the roles of other departments. It leads to a greater understanding of the broader business context; an understanding of talent and recruitment challenges; cross-training and better teamwork. Okay so now you’ve kicked these silos into touch what next?

Daily cross-functional meetings

One of the critical aspects of Agile is the daily stand-up meeting (so-called because it’s daily and you stand up for the meeting to keep things brief!) The success of the meeting is its fiendish simplicity. One person is dedicated as the lead for the meeting to ensure the meeting happens, keeps it moving along by ensuring detailed topics are taken offline. This person also ensures items are tracked. Each team member speaks very briefly. They say
1. What they did yesterday (brief update but also ensures people keep their commitments
2. Plans for the day ( what are they committing to do today)
3. Blockers or help needed. In this quick meeting (15- 20 minutes depending on the size of the team) everyone learns what other team members are focusing on, can see how they can help if required, make suggestions and bring others up to speed with their focus areas.
What I have found since I was introduced to the concept of the stand-up meeting is that it is a very quick way to exchange a lot of information as quick headlines rather than having to go through slides for updates. The meetings stop duplication of effort, which can sometimes happen in HR helpdesk environments. It also provides a broader context for the team about the workload of each team member and allows those with a reduced workload to step up and help. It reduces the need for lots of other meetings. For HR teams, I insist on doing stand-ups in an office and a commitment from participants that absolutely nothing confidential is mentioned outside the stand-up space and that employee personal matters are not discussed in this format with the broader team.

I really think your teams will enjoy the format if you add pastries to the occasional meeting you will get additional brownie points. As a manager you can check in on stress levels, happiness index whatever your temperature check mechanism is. I can’t predict what will happen in your teams but each time I have implemented this I have seen less stress, a greater feeling of “being on top of things” and from teams a sense that they are at once empowered by managers and supported by colleagues.

Why not give those ideas a go and let me know how you get on? Next time I will talk about some common digital tools that will help with organising your team workload and improve team communication both with HR and the customer organisations you support.

Learn More About Ammeon’s Agile Processes

By James Ryan, Head of HR and Operational Development at Ammeon

I was delighted to have been asked to talk about my journey into AgileHR at the Agile Lean Ireland event in Croke Park in Dublin in April. Despite overwhelming imposter syndrome talking about Agile to a room full of Product Owners and Scrum Masters, I was happy to see a connection being made with these experts by using language and terms which they were familiar. What was sad from my perspective was how few HR people were at the conference despite the HR focus. For those of us from HR who were there, it was a wake-up call.

As a long term HR professional I sat in awe as the giants of the Agile world such as Barry O’Reilly and Mary Poppendieck talked about applying agile principles to massive technology projects – and that these incredible achievements were less about the tools but the product of a people-centric mindset: teamwork, coaching, innovation, leadership, mentoring and facilitation. Surely, I thought to myself, this list of skills belongs on HR’s turf!

Well, I’m sorry fellow HR folks but while we have been hiding behind compliance, admin and working on yet another iteration of annual performance reviews the technology world has moved on without us, developing a set of people principles which is driving development in everything from AI to space rockets.

So how do we get back in the game? Have we missed the boat? Well, no. The good news is there is a quiet revolution going on in the HR world. The agile mindset is being applied to HR and is being driven by thought leaders in this area: the great Kevin Empey, Pia-Maria Thoren and Fabiola Eyholzer are evangelising the AgileHR message to enthusiastic audiences worldwide. It’s clear that despite being slow off the blocks, HR professionals have all the skills and competencies to be more than just bit players in the future of work – we can utilise our natural skills to bring strategic value to our businesses.

Over the next few articles, I am going to be talking about how you can quickly and easily begin to introduce Agile practices supercharge both your team’s performance and the perception of the people function within your organisation. Sounds good? Stay tuned.

Learn More About Ammeon’s Agile Processes

By James Ryan, Head of HR and Operational Development at Ammeon

The Scrum Guide, the official definition of Scrum, created and described the role of Product Owner (PO). The role is described as “responsible for maximizing the value of the product and the work of the Development Team” [1]. It’s a challenging role; as it requires someone with technical ability, business analysis ability and authority to make decisions and deal with the consequences. It is often considered to be the most difficult role in Scrum [2, 3, 4].

There are a number of tools available that can help the Product Owner be successful. This post describes one such tool, called the PICK chart, which can be used to aid planning and prioritisation between the development team and the stakeholders in the business.

PICK your Stories (and Battles)

The Scrum Guide describes the Product Owner’s responsibility as “the sole person responsible for managing the Product Backlog” [1]. Commonly this is interpreted to mean that the product backlog is a one-dimensional list of tickets ranked by business value. This is a bad idea. By ordering in this simplistic manner, some low-value stories remain untouched by the team for a very long time (sometimes years). The stakeholders who requested this work are effectively placed at the end of a queue only to see others skipping in front of them.

At the top of the product backlog, a one-dimensional list also causes problems for the unwitting Product Owner. This is because some valuable tasks are straightforward to implement and others are complicated or have very high levels of uncertainty.

The INVEST [5] and MoSCoW [6] techniques can help improve story refinement and prioritisation. INVEST ensures that each story satisfies certain criteria. It doesn’t provide a ranking criteria as long as these criteria are met.  MoSCoW provides a method for managing project scope and identifying out-of-scope and at-risk items. It tends to be subjective and why an item is in one of its four categories rather than another can be contentious.

A PICK chart, similar to the one shown below, is a useful method of addressing the weaknesses of existing methods while also meeting the needs of the team and stakeholders:

This two-dimensional chart shows both the potential value and the likely difficulty of each story. The y-axis shows the value (“payoff”) from delivering story and ranks the highest value to the top. This is similar to the usual lists used to display product backlogs. The x-axis shows the effort required to deliver a story. Stories on the left have lower risk as the effort required to deliver is less than those further to the right.

The PICK chart can be used effectively during sprint planning to help the Development Team select stories that can be implemented in the next sprint as well as identify work that needs further investigation. This helps ensure the sprint does not consist entirely of high-effort, high-risk stories.

The chart can also be used as a visual tool to remove stories from the bottom of the backlog because they are both low-value and technically challenging. Involving some or all of the team in backlog grooming gives a degree of empowerment to the work they will and won’t work on incoming sprints. The outcome of this analysis simplifies the conversation with stakeholders who need to be told their idea will never be worked on. Instead of it being your opinion versus theirs, there is business and technical justification.

The PICK chart is a powerful tool in any Product Owner’s arsenal. By eliminating long wait times for features that will never be delivered, it ensures that internal stakeholders don’t waste time on false hopes. By ensuring work is delivered in each sprint, the team are seen to be continuously reducing risk and adding value to the product. Its visual nature and relative ranking in business and technical dimensions mean there are fewer heated arguments between teams, stakeholders and the Product Owner. It makes “the most difficult role” that little bit easier.

References:

1. K. Schwaber, J. Sutherland, The Scrum Guide, July 2016, [Online] http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf. [Accessed 6 June 2017]
2. A. Johnson, The Most Difficult Role in Scrum: the Product Owner, April 2016, [Online]  https://www.collaborativeleadershipteam.com/blog/2016/4/27/the-most-difficult-role-in-scrum-the-product-owner [Accessed 6 June 2017]
3. A. Johnson, The Product Owner-the most difficult role in Scrum: Webinar Q&A, January 2016, [Online]  https://www.watermarklearning.com/blog/product-owner-scrum-webinar/ [Accessed 6 June 2017]
4. R. Pichler, Avoiding Common Product Owner Mistakes, February 2010, [Online] http://www.romanpichler.com/blog/avoiding-common-product-owner-mistake/ [Accessed 6 June 2017]
5. Agile Alliance, INVEST Glossary Definition, [Online] https://www.agilealliance.org/glossary/invest [Accessed 6 June 2017]
6. Agile Business Consortium, DSDM Atern Handbook, chapter 10: MoSCoW Prioritisation, 2008, https://www.agilebusiness.org/content/moscow-prioritisation-0 [Accessed 6 June 2017]

Picture Credit:

Header picture from http://www.tradingacademy.com

By Rob Healy, Principal Consultant at Ammeon

Learn More About Ammeon’s Agile Processes

This 2 day Business Agility Workshop you will use simulations to engage the intuitive as well as the rational brain while learning about the foundations of business agility.

Date: 21st & 22nd November, 2018

Location: Ammeon Learning Centre, O’Connell Bridge House, Dublin 2

It is more than scaling agile (development) practices. It is more than the sum of different organisational units that each implement their own chosen agile method on their own little island, constrained by a traditional management system. It is a different way of thinking about agility.

BUSINESS AGILITY WORKSHOP WILL GIVE YOU: 

– New ways of teaching and coaching agility that engages and mobilizes all levels of the organisation (including decision makers) across all functions (not just IT or software development).

– A different way of thinking about change where agility spreads virally through the (informal) network. – Agile thinking at scale to develop unique capabilities to thrive in an ever-changing and highly competitive business landscape .

1. ENTERPRISE FLOW that balances supply with demand from team to portfolio level,
2. NETWORKED COLLABORATION where highly engaged teams work, decide and learn together in a network,
3. ORGANISATIONAL LEARNING where experience and experiment complement each other,

DAY 1 – CORE AGILE CAPABILITIES

• Explore flow, collaboration and learning as core agile capabilities as opposed to methods and practices that do not scale
• Learn how to use simulation as a way of teaching and coaching the core agile capabilities in a way that inspires action not just talk
• Experience how to teach agility at all levels and across all functions (not just IT) in the organisation

DAY 2 – SCALED AGILE THINKING

• Learn about enterprise flow, networked collaboration and organisational learning as the core capabilities for business agility

• Use simulation to explore scaling problems including cross-team dependencies and balancing demand with supply in end-to-end flow
• Explore the use of Customer Kanban to manage capacity downstream, and triage and order points to shape demand upstream. Apply what has been learned in the context of agile portfolio management.

Who the workshop is targeted at?

The workshop is intended for agile coaches and practitioners who want to engage business as well as IT (including decision makers) in their agile initiatives. It is a must for coaches and trainers who want to use Okaloa Flowlab in their own training and workshops.

Facilitator Bio’s 

Patrick Steyaert of Okaloa, a principal lean agile coach with extensive experience in practicing Kanban, will be your workshop facilitator. Patrick received a Brickell Key Award in 2015 as a recognition for his contributions to the Kanban community. Patrick is one of the first, and only Belgian, Lean Kanban University accredited trainers. He is also a regular speaker at Kanban and agile conferences.