The Seven Pillars of Agile – Self-Improvement

One in a series on the Seven Pillars of Agile retrospective.

Self-Improvement

To what extent do you agree that each statement below is true of your team ?

  • Continuous Improvement

    • We improve ourselves as a team over time

    • Our team supports individual self-improvement

    • We are always open to any new technology or idea that may help us achieve our goals

  • Intentional Practice

    • We read books that inform our work

    • We discuss how we work and consider opportunities for improvement

    • We participate in code katas / code dojos to improve our skills

    • We attend conferences and events where we can learn from experts in our field

    • We contribute to Open Source projects

  • Introspection

    • After any problem, we consider how we could do better next time

    • We hold regular Team Retrospectives, and use them to improve how the team works

  • Balance

    • I maintain motivation in my work

    • I have a sustainable Work/Life balance

    • We have regular slack time, rather than sustaining 100% effort continuously

 

The Seven Pillars of Agile – Technical Excellence

One in a series on the Seven Pillars of Agile retrospective.

Technical Excellence

To what extent do you agree that each statement below is true of your team ?

  • Considered Design

    • We consider multiple possible ways to satisfy each business need, and make informed choices to achieve the best functionality, usability, and long-term sustainability

    • Our designs allow us to move forwards at a steady pace, without unpleasant surprises or panics

    • We keep technical debt manageable, and keep our design under control without requiring excessive quantities of rework

    • We consider our users performance requirements for each feature, and strive to meet or exceed them.

  • High Quality Implementation

    • Our code is clear and simple – “Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away”

    • Don’t Repeat Yourself – we refactor when we spot repetition. Are your ‘C’ and ‘V’ keys showing more wear than the rest ?

    • Cohesive, Single Responsibility classes – we don’t have big, bad classes; and if we encounter such beasts, we trim them rather than allowing ourselves to add to them.

    • We don’t abuse inheritance – our subclasses are genuinely substitutable

    • Our collaborators Tell each other what to do, rather than Asking for information

    • Our tests are fit for purpose – expressive to read, flexible to change, and reliable to run

     

 

The Seven Pillars of Agile – Confidence

One in a series on the Seven Pillars of Agile retrospective.

Confidence

To what extent do you agree that each statement below is true of your team ?

  • Code Confidence

    • Confident that the code actually meets the user requirement

    • Before passing a card on for testing , we are confident that the feature works properly under all likely use cases – not just “done”, but “Done Done”

    • There is no ‘actually, we also need to…’ or ‘other 80% of the work’

    • Zero Bugs process – don’t just fix the bug, fix the process to eliminate the source of the bug

  • Process Confidence

    • We use version control effectively to ensure that we know what we deliver

    • Our Continuous Integration system gives us clear, timely feedback on our code

    • Our progress is transparent to all members of the team and to outside stakeholders

    • We maintain a shared team rhythm, e.g. all being present for the morning standup

 

The Seven Pillars of Agile – Supportive Culture

One in a series on the Seven Pillars of Agile retrospective.

Supportive Culture:

To what extent do you agree that each statement below is true of your team ?

  • Learning

    • Everything we do, we treat as an opportunity to learn

    • We embrace the face that when we a task is completed, we’ll see more clearly what we should have done – and use this to help us see what to do next.

  • Space to Learn

    • We have a ‘No Blame’ culture

    • An appropriate proportion of slack time – to stop, think and experiment

    • We celebrate failure as an opportunity to learn

    • We take appropriate risks

  • Managing Conflicts

    • We avoid allowing conflict to damage the team

      • wasted energy

      • disappointment

      • individuals feeling disengaged from the team effort

    • We extract value from a diversity of opinion

  • Respect

    • I trust my colleagues

    • I feel trusted by my colleagues

    • Our team is trusted by the rest of the business

    • Individuals and the team feel empowered to tackle challenges themselves, without waiting for senior assistance or permission

  • Commitment

    • Each team member is always nudging for improvement

    • We are willing to ask for help, and to give help when asked

    • Whole Team Attitude (we all own the whole product)

    • Permanent Team Attitude (stability, shared history, commitment to a shared future)

 

 

The Seven Pillars of Agile and the Spiderweb Retrospective

As part of our efforts to continuously improve our team’s working process, we hold Agile Retrospectives every couple of weeks. A feeling arose in the team that our existing retros were getting a bit stale, so as the facilitator, I was tasked with running the next one ‘completely differently’.

I discovered Brian Marick’s Pillar Spiderweb Retrospectives; the spiderweb is nicely visual, and by asking participants to focus on specific areas, should help bring up possible areas for improvement that might otherwise escape consideration.

Probably the most crucial part of making these discussions fruitful is the initial description to the group of what each specific ‘pillar’ means. In order to elicit a comparable set of ratings and a productive discussion, it is critical to establish a shared understanding first.

Helpfully, Brian also wrote up sets of notes for three of the seven pillars on his blog, describing and giving examples of what they mean in practice:

To support discussion of the other four pillars, I’ve assembled some notes, based closely upon the descriptions in the Agile Skills Project Wiki:

Since I only sat down to write these notes after exhaustive Googling appeared to show that no-one else had done it for me, I thought they’d be worth sharing here, in the hope that they help others try out the Agile Pillars Retrospective.

Our Pillar Spiderweb retro seemed to succeed in enabling discussion of points that hadn’t otherwise been considered, and at the end there was a strong team consensus that it had been worthwhile. The team agreed that they want to repeat this format of Retro at three-monthly intervals.

See also:

Brian Marick’s original blog post: http://www.exampler.com/blog/2009/06/10/the-seven-pillars-of-an-agile-team-introduction/

The Agile Skills Project Wiki: http://sites.google.com/site/agileskillsprojectwiki/

The Mind Map of Agile Skills: http://www.mindmeister.com/35781546/seven-pillars

 

Annual Stack Overflow Meetup Day @ youDevise London

Last week was the Annual Stack Overflow Meetup Day. youDevise was proud to host the London meetup for this worldwide event. Our dev teams work almost exclusively with open source tools and frameworks to deliver high-quality on-demand financial applications. Many of our coders are active contributors to Stack Overflow and all of us have benefited from the advice we find (and provide!) there.

Over 40 people filled up the 4th floor of our London City offices last Wednesday night. Mounds of pizza were enjoyed by all, and many brave souls tried their hands (actually their whole bodies!) at a few rounds on the Kinect we set up in the board room. We had a second big screen set up to watch the #SOMeetup-tagged tweets coming in from all over the globe as we joined in on the truly world-wide event.

It was a great way to give something back to a community that’s given a lot of help to us, and we had loads of fun doing it. Big thanks to everyone who made it out, it was great to get to meet you!