This page provides a high-level introduction to various aspects of what we do at CrackAgile. If there are any topics you believe should be covered here, but are not; please get in touch to let us know.
What is Agile?
Well, first… what agile isn’t:
Agile isn’t a methodology, but rather an umbrella term for a group of delivery methodologies based on similar mindsets. It is kind of like having a big tool box. You take what you need to get the job done and leave the rest in there for another day, or another worker to use.
Formally, agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.
Whereas the traditional waterfall approach has one discipline contribute to the project, then hand the baton over to the next contributor, agile operates around collaborative cross-functional teams. Open communication, collaboration, adaptation, and trust amongst team members are at the heart of agile. Although the project lead or product owner typically prioritises the work to be delivered, the team takes the lead on deciding how the work will get done, self-organising around tasks and assignments.
Agile isn’t defined by a set of ceremonies or specific development techniques. Rather, agile is (as mentioned above) a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement.
The original Agile Manifesto didn’t prescribe two-week iterations or an ideal team size. It simply laid out a set of core values that put people first. The way you and your team live those values today – whether you do Scrum by the book, or make up your own blend such as using elements of Kanban and XP – is entirely up to you.
Why choose agile?
Teams choose agile so they can respond to changes in the marketplace or feedback from customers quickly without derailing a year’s worth of plans. Planning is minimal and shipping in small, frequent increments lets your team gather feedback on each change and integrate it into future plans at minimal cost. In software delivery, the first thing to do in an agile project is to start coding. Without that you have nothing to improve on.
The Agile Manifesto outlines how authentic human interactions are more important than rigid processes. Collaborating with customers and teammates is more important than predefined arrangements. And delivering a working solution to the customer’s problem is more important than hyper-detailed documentation.
An agile team unites under a shared vision, then brings it to life the way they know is best. Each team sets their own standards for quality, usability, and completeness. Their “definition of done” then informs how fast they’ll churn the work out. Although it can be scary at first, company leaders find that when they put their trust in an agile team, that team feels a greater sense of ownership and rises to meet and exceed expectations.
Unfortunately, many large organisations take a “let’s do Agile” approach without truly thinking it through. Used to traditional Waterfall programmes & projects, they try to shoehorn agile ways of working into their current set-up. While some hybrid programmes work well, many others fall by the wayside as soon as management teams get out of their comfort zone. If time is taken to invest in the right people, agile deliveries can transform customer receipts dramatically – from small start-ups to global organisations.
Agile values and principles
The Agile values, as outlined in the Agile Manifesto are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation;
- Customer collaboration over contract negotiation; and.
- Responding to change over following a plan.
This doesn’t mean everything on the right gets ignored. Put simply it means, if all things are equal, the activities on the left should be given priority over those on the right.
The Agile principles are:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organising teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Looking for some further reading on Agile?
Well, there are hundreds of good (and not so good) books out there. An interesting recent find was Klaus Leopold’s ‘Rethinking Agile‘. Just click on the link to be taken to Amazon for a look. More options can be found on the suggested reading page.
For the record, if you use the Amazon link above, a fee may be paid to our parent company. This is at no additional cost to you. Further details can be found on our disclaimer page .
Please let us know what you think of this article. Feel free to challenge anything you don’t agree with – Transparency is progress .
What is SAFe®?
SAFe® stands for the Scaled Agile Framework. It is an agile delivery method designed to enable faster deployment of customer centric needs. Built to encompass the entire portfolio (Portfolio, Programme & Team) it is a wide ranging opportunities for those looking to deliver based on a customer focused mindset.
SAFe® is designed to give a team flexibility and to help manage some of the challenges larger organisations have when practicing agile. It is designed not so much as a single methodology, but as a broad knowledge base of proven best practices that real teams have used to deliver successful software products.
There are other scaled methodologies out there. SAFe® isn’t by any means the perfect solution for every delivery, but it has gained traction due to the freedom to cherry-pick the bits you need and maintain collaboration whether your delivery is programme, portfolio or enterprise.
What’s the History of the Scaled Agile Framework?
The SAFe® framework was introduced in 2011. The Big Picture at that time described how to leverage existing agile frameworks such as Lean, Kanban, Scrum, & XP and apply them at the portfolio to team levels.
Today, SAFe’s entire catalogue of knowledge and success patterns is all available for free, and it has become one of the most popular agile frameworks.
What are the Strengths and Weakness of SAFe®?
SAFe’s strengths include:
- Helps cross-functional teams collaborate more effectively
- Helps organizations achieve greater transparency
- Aligns all aspects of a project to the broader business goals
SAFe’s weaknesses include:
- Some believe the framework is not pure agile, because it requires a lot of planning and process definition
- It also takes more of a top-down approach rather than a team-based approach
Looking for some further reading. Try John P. Kotter’s ‘Leading Change‘. Just click the link to see more about this on Amazon. More options can be found on the suggested reading page.
For the record, if you use the Amazon link above, a fee may be paid to our parent company. This is at no additional cost to you. Further details can be found on our disclaimer page.
Please let us know what you think of this article. Feel free to challenge anything you don’t agree with – Transparency is progress.
What is DevOps?
One of the most difficult milestones in any software or change delivery is promotion to a live environment, or Go Live. This is traditionally down to the different priorities of the delivery team and the operations teams. The delivery team start development, engage with application support (or whoever the appropriate team responsible for maintaining the delivery once it goes live) and realises this team have their own set of priorities to keep the show on the road before accepting anything new into the mix
This is where DevOps comes into it’s own.
As the name suggests, DevOps is a combination of the Development team and the Operations team. There is another reference used when the DevOps team are primarily interested in producing security related output. In this case DevOps becomes DevSecOps.
By working together they can quickly automate delivery processes in hours or days that would have previously have taken months, or even years, to go live. But speed of delivery is only one of the many DevOps benefits. With continuous delivery comes continuous integration with current systems. This enables integration fixes to be made rapidly, which enhances the rigidity of the overall system. With rapidly increasing rigidity and confidence comes the ability to scale deliveries at speed. This is why DevOps work so well within scaled frameworks like SAFe.
If you’re interested in a novel way of learning more on DevOps, try The Pheonix Project. Just click on the link to be taken to Amazon for a look. More options can be found on the suggested reading page.
For the record, if you use the Amazon link above, a fee may be paid to our parent company. This is at no additional cost to you. Further details can be found on our disclaimer page.
Please let us know what you think of this article. Feel free to challenge anything you don’t agree with – Transparency is progress.
What is XP?
Extreme Programming evolved from the quick turnaround demands experienced during the dot-com boom of the 1990s. Although the dot-com bubble burst, the benefits of XP were clear and software development has embraced it ever since. As methodologies go, XP can confidently stand on its own two feet. However, the benefits can be witnessed best when part of DevOps deliveries. Mix DevOps/XP with scaled delivery, such as SAFe and it can really take-off – helping get your minimum marketable feature in front of investors and budget holders in staggeringly quick time.
The ethos of XP revolves around rules, values and activities. A lot of software developers like to jump straight to the activities. After all, that’s the doing part. The interesting part. But since you’re reading this, and not coding, I’ll follow the logical sequence here:
Rules
There are a few versions of XP rules. Those outlined here are the original 29 created by Don Wells in the early days of XP. Whichever version you refer to, the focus should be on how the rules enable the free & easy attitude of XP to be controlled as an enabler to ensure integration with wider Agile ways of working. As you will see, the Agile mindset runs through all methodologies.
Planning Rules
- User stories are written.
- Release planning creates the release schedule.
- Make frequent small releases.
- The project is divided into iterations.
- Iteration planning starts each iteration.
Managing Rules
- Give the team a dedicated open work space.
- Set a sustainable pace.
- A stand-up meeting starts each day.
- The project velocity is measured.
- Move people around.
- Fix XP when it breaks.
Designing Rules
- Simplicity.
- Choose a system metaphor.
- Use CRC cards for design sessions.
- Create spike solutions to reduce risk.
- No functionality is added early.
- Refactor whenever and wherever possible.
Coding Rules
- The customer is always available.
- Code must be written to agreed standards.
- Code the unit test first.
- All production code is pair programmed.
- Only one pair integrates code at a time.
- Integrate often.
- Set-up a dedicated integration computer.
- Use collective ownership.
Testing Rules
- All code must have unit tests
- All code must pass all unit tests before it can be released.
- When a bug is found, tests are created.
- Acceptance tests are run often and the score is published.
Values
- Communication
Ordinarily, software development would entail a team member (often a Business Analyst) speaking with the end user and capturing what they want the solution to do for them. These days, this would be written-up as user stories with acceptance criteria (if you’re old-school, think requirements and rationale).
However, by the time one or 2 BAs get time with the end-user and capture their ask, take that back to their desks, write-up all the user stories and confirm the acceptance criteria; a good XP duo will have at least the first iteration done and unit tested. How do they do that? Rule number one: The customer is always available. Get the end-user in the same room, or Zoom, as all of the developers and have them explain what they want the solution to do. Not every detail. Just enough for the first iteration and permit the developers to ask as many questions as they see fit. That way every programmer working on the solution will understand exactly the same as everyone else. Even if the end-user changes their mind later, there’s no confusion as to what everyone should be working towards. Communication is key.
For clarity, I’m not saying user stories and acceptance criteria should be ignored. The team should still write these, but they will provide more use at testing than during initial coding.
- Simplicity
There’s a trade-off here. The ideal XP scenario is to work towards a Minimum Marketable Feature (MMF), which is even less than the more widely used Minimum Viable Product (MVP) as you are not looking for a saleable product – just evidence your offering works. The aim is to get the simplest code in place, try to break it and iterate from that point until you get what the customer wants.
So what’s the trade-off?
Completeness.
XP, and wider Agile software delivery, at its simplest is: Just Start Coding. To get the best out of this mindset you must be willing to forego the (often misplaced) confidence you would have if your plan stretched further than just today.
- Feedback
Feedback can be broken into 2 categories; automated and human.
Automated feedback comes from testing, mainly unit testing within the dev team and user acceptance testing from the customer. UAT crosses the 2 categories with the end-user providing human feedback in addition to the acceptance test output.
The main human feedback, however, comes from collaboration within the dev team and how the team interacts with the customer. Within the team it is important all members keep themselves in the loop with regards to how the ask and solution are evolving. Customer interaction needs to be managed carefully. Scrum Masters are particularly good at this as developing and maintaining a wealth of stakeholder relationships are a large part of the SM skillset.
- Courage
XP enthusiasts have a proactive mindset. This is why they work well in DevOps teams. Being comfortable in that mindset takes courage. Courage not to be sidetracked by the old ways of doing things. Traditional programme and project managers like to have an end to end plan. Not having that E2E plan scares them. How do you justify your existence with an ‘Everything will be fine’ attitude?
As traditionally minded change and development personalities move into Agile ways of working they have to face their fears. A gant chart isn’t much use to you when you don’t know what is happening tomorrow, never mind in 6 months time. Embracing a Just Do It attitude is an absolute must when getting the most out of trusted proactive people.
Coders themselves need courage too. Courage to be comfortable knowing their code may need refactored. Courage to understand sunk-costs. Knowing some of that hard-grafted code will need binned if the solution is to meet the end-user’s needs. Courage to battle through, even when complexity is wearing them down and self-doubt kicks-in.
All of these activities, attitudes and more take courage. But the foundation of it all is the XP mindset.
- Respect
None of the above values would mean anything if there was a lack of respect in the team. Respect covers everyone; self, team-members, end-users and external stakeholders. If leadership can ensure the strategic theme is understood by everyone with a role to play in the solution then each of those role-players have skin in the game.
That sense of responsibility empowers each player to do what is right for themselves, but only if it is right for everyone. As described elsewhere in this article, logical design helps highlight how separate elements of the solution will be integrated. As such, one coder has a responsibility to respect the work of those who delivered before. You don’t break somebody else’s code just to make yours work. You refactor it to make the solution work. If the team is gelled in the way it should be, this issue is likely to rarely occur as integration will be part of continuous discussion.
Activities
- Coding
There’s an old adage that the first activity in any agile project is to start coding. It makes sense. Without code you have no product to improve upon. This is particularly beneficial if a programmer finds it difficult to describe a complex solution. They can code it and other programmers can assess the code and provide feedback. This is an integral mindset in XP, as the remaining activities will elaborate.
- Testing
Test-driven development (TDD) is what provides confidence in the ability for XP programmers to deliver. Kent Beck (sometimes referred to as the father of XP) wrote in his book, Extreme Programming Explained, that testing is what sets XP apart from other programming mindsets. Flagging a few flaws in early testing can have a significant domino effect when considering the amount of testing you can complete through to final solution delivery. The XP testing goal is simple; try to break the code. Once that ask is satisfied, Acceptance Testing needs to ensure the robust code meets the client’s original requirements, which leads us to…
- Listening
This can often be the activity many programmers enjoy least. That’s because it means stop doing what you love most and go talk to people who often don’t understand what you do anyway. However, most programmers (the ones you want on your XP features) understand what most change management people don’t. They’re different. Not in a ‘proud to be a geek’ kinda way, but the nature of programming means coders structure their day differently to other project people – and it’s something non-programmers would benefit from learning. Put simply, programmers are makers and others are managers. Managers chop their workdays into half-hour chunks and float from one activity or meeting to another. Makers, on the other hand have little interest in meetings. Quite rightly, they want to get on with developing the solution. To enable this, they typically break their workday into only 2 chunks:
- Before lunch
- After lunch.
If you’re a non-programmer and struggling to get a developer to attend meetings, try asking them for a suggested time. You’ll probably find it is outside of the 2 maker-chunks.
- Designing
Why design? Why forward plan, when the ethos of agile is to iterate and make the now better?
Well, standalone iteration is great until you have to integrate with another part you’re your system or even a completely separate system. XP within DevOps handles this well, but you don’t necessarily need DevOps to consider design. A good start is a logical data model (LDM). It doesn’t need to be physicalised at this stage. Just use it to see how each handshake occurs and let that steer your scale discussions.
Hopefully, this slightly longer article has been of use to you. If you want to learn more about XP, Kent Beck’s book ‘Extreme Programming Explained’ is a great place to start. Just click on the link to be taken to Amazon for a look. More options can be found on our suggested reading page.
For the record, if you use the Amazon link above, a fee may be paid to our parent company. This is at no additional cost to you. Further details can be found on our disclaimer page.
Please let us know what you think of this article. Feel free to challenge anything you don’t agree with – Transparency is progress.