You are currently browsing the tag archive for the ‘xp’ tag.
It was a wonderful event, full of Agile content made possible by keen Agilists!
This event was proudly sponsored by:
 |
 |
As promised, herewith the content from the event:
Agile Engineering Practices:
( Click here to download a PDF version of the presentation )
Lionel talking to us about Agile Engineering Practices
Trying to cover Agile Engineering practices in 30 minutes is pretty tough – there will always be a different way to do it. What Lionel tried to do was ignore specific code or technical aspects, and to present the essence of what Agile engineering is.
Summed up from the presentation it is:
- Let the “7 lean principles” and “7 wastes to be wary of” guide your every decision
- Software is part engineering and part craft – practice your craft and be proud of what you do
- Run a clean and efficient workshop through “Sort, Systematize, Standardize, Shine, Sustain” – for all your tools and code
- Code must be read and re-understood many, many times over, by humans, therefore code should be as clear and “English” as possible – use abstraction and a never ending focus on good naming of abstracted logic to achieve this
- Test driven development is the best process to achieve good, modular, well named code developed in a highly iterative fashion
- Design in the large follows the same principles as design in the small – use interfaces, abstractions and ensure single responsibilities
- Quilt coding – by having cohesive but loosely coupled components working through stable interfaces where separation of concerns have been achieved, one approaches the situation where multiple functional components can be stitched together as and when their functionality is needed
- When tackling a big new system, go breadth first, and only when really needed go deep to prove a certain functionality or technology. Where to go deep is driven by the risk associated with functional and technical unknowns – don’t go deeper than what is needed to reduce risk to an acceptable level – then repeat for remaining risk areas across the breadth. Follow lean principles
- Use sensible, repeatable, maximally automated release processes all the way from a workstation to dev to integration to qa to uat to live. Be able to roll forward and back to any point in time on the code and database.
- Use Agile version control methods – good introduction by Henrik Kniberg at http://www.infoq.com/articles/agile-version-control
- If you do the above, you do not need Big Design Upfront (BDUF). In fact, you will beat a BDUF approach every time, since you can change your mind at multiple levels in your solution stack and between components, with TDD watching your back
- Stay lean – question the status quo – build your craft
Kanban Case Study – Educos
( Click here to download a PDF version of the presentation )
Liz talking to us on Kanban at Educos
Liz Bath from Educos Vision Services, http://www.educos.co.za, then went ahead and treated the audience with a well-prepared case study on the effects of Kanban as an Agile solution to Service Support within Educos…
This was an eye-opener and definitely opened-up some minds during the presentation…
Thanks Liz and all from Educos, not just for the Case Study, but also for the lovely gifts everyone received!
The committee would like to thank each and everyone who attended, and for those who could not make it, well, hope to see you next time, we hope these presentations will convince you to make the time!
Book the next event so long, we are tentatively planning the next event for 1 October 2008, and if you would be interested in speaking at the event, please send us your details and proposed topic to agile@kaizania.co.za.
We are also looking for venue sponsors for the evening, please mail Arrie van der Dussen at agile@kaizania.co.za may you be willing to either provide us with a suitable venue or willing to assist in paying for a suitable venue…
Keep Scrumming!
The Cape Town chapter of the Scrum User Group of South Africa held it’s 4th event last night. We met at Great Westerford, with venue and food kindly sponsored by Intec and drinks sponsored by Scrum Sense.
Hilton Giesenow, Development Manager at 3Fifteen and Microsoft MVP spoke on continuous integration (CI) in Scrum. A brief summary of his talk at http://www.scrum.org.za/events/hilton-giesenow-on-continuous-integration-in-scrum
The SUGSA Gauteng event is planned for 21 May 2009 at Momentum in Centurion, with food and drinks sponsored by Kaizania.
For more information and to register for the event, please go to http://www.scrum.org.za/events/scrum-user-group-south-africa-gauteng-event-4-21-may-2009
Kind regards
Arrie van der Dussen
Agile Business Manager | Agile consultant
Kaizania
On Thursday (2 April) I was present at an IBM sponsored talk on Agile. Some luminaries of the Agile world were present. They covered the usual Agile ground and all was good in that respect. What saddened me was the intermittent bashing of anything not RUP. Interspersed, grudgingly, was admittance that others had a good point here and there. Now that the pioneers have convinced the world, the heavies are moving in and the smell of money is in the air.
I heard the same kind of negative views and sniping at RUP from a SCRUM trainer recently. “RUP is not Agile, don’t believe their new marketing spin” etc. etc.
Most of the Agile techniques are based on what the folks in consumer product development and manufacturing learnt. Some new stuff here yes, but let’s not get carried away with how smart and righteous certain software people are.
All the pioneers in Agile contributed to our better understanding of how to develop software. Some of what they said overlapped; some of what was said by each approach was unique. The Agile manifesto was the culmination of theses separate efforts, joined together as an Agile whole – better and stronger.
What did each uniquely contribute? My views, typed up in 5 minutes, but bash me if you really need to and think I deserve it……..:
XP
- Stories
- Test driven development
- Continuous integration
- Continuous refactoring
Scrum
- Self organization
- Plan – Do – Check – Adapt; Continuous improvement; Kaizen
RUP
- Attack highest risk issues first
- Architecture and component driven
Lean
- Deliver the right product at the right time at the right price
- What does not benefit the end customer is waste
- Eliminate all forms of waste
- Challenge the status quo
DSDM
- Time box
- Flexible requirements – not flexible budgets and release dates
FDD
- Plan, deliver and organize based on features and business value, not tasks
When I now hear the RUP, SCRUM, DSDM, FDD, XP, Crystal etc. zealots bash each other I wonder where the Agile values are. One of them is RESPECT. So please, even though money is at stake, try to show some.
Where have all the values gone?
Long time passing
Where have all the values gone?
Long time ago
Where have all the values gone?
Sold for a dollar every one
When will they ever learn?
When will they ever learn?
Lionel Bisschoff
CEO, Kaizania
Losing the Agile plot…
October 21, 2009 in Agile Commentary, Scrum Coaching | Tags: adopting agile, coaching, consulting, implementing scrum, kanban, what is scrum?, xp | by thinkingagile | 2 comments
What is the essence of Agile?
This is the question any individual, team or organisation thinking of adopting agile needs to be able to answer first!
Too many agile implementations are based on tools and recipes, yes; Scrum / XP/ Kanban are agile tools. On their own, they won’t make you agile and focusing on the recipes and processes they prescribe on its own won’t bring you to the goal of extreme business value.
Coaching many teams and many organisations in South Africa and listening to the comments when training numerous organisations on Agile, it is clear to me as an Agile coach that individuals and organisations want the benefits of Agile, however, still want to grab a silver bullet like Scrum or XP or DSDM etc.
Agile tools won’t make you Agile, they are not silver bullets, they are purely tools to assist your agile implementation in a structured, well organised manner.
To really understand the issue at hand, we first need to admit that the problem we are faced today is people and not technology.
Once you admit this, then you can take the first step towards realising the benefits gained from an Agile approach.
A lot has been written on ‘Cargo-Cult Scrum’, I would like to take it further and name it ‘Cargo-Cult Agile’. This is where organisations or teams reach for Agile tools and hope that by following the simple rules and processes prescribed by that tool, that they will experience rapid benefits.
Then the organisation or team fails and keep failing and eventually they blame Agile, however, they never addressed the essence of Agile!
The problem we face is people, not technology!
Most organisations or teams implementing Agile have some debt to pay before they can even think of reaping Agile benefits, yet, most of the time, this debt is ignored and it’s an elephant in the room no-one wants to talk about, yet, everyone knows its there. Easier to ignore, than to admit the elephant is taking up all the space you need to be truly Agile…
So, when I talk about debt to be paid, what am I referring to?
3 types of debt:
Knowledge debt:
Agile is built around teams, yet teams can only perform as fast as the slowest member. The knowledge gap between individuals making up a team needs to be addressed and fast. This is where Agile tools do play a role with ceremonies like planning as a team, daily co-ordination meetings, reviews and retrospectives. Yet, by having these ceremonies without the true context of paying your knowledge debt, these ceremonies are again an empty shell without real value.
Technical debt:
The first thing to an Agile implementation is that Quality is non-negotiable. This usually sounds fantastic and provides everyone with a warm and fuzzy feeling; from now on we are only going to deliver high quality products and faster as we are now agile…
In reality the opposite is true, we work towards quality, but we deliver slower and this is due to technical debt…
Because of the quality standard which we will not negotiate on, there is no room for quick and dirty development, let’s face it, it is the quick and dirty development without proper refactoring which caused the technical debt in the first place…
An organisation or team would need to understand that they would need an aggressive approach to pay their technical debt as quick as possible. This will cause a dip in productivity during the first period, but the productivity will increase exponentially after a short time…
If there is no aggressive approach to paying technical debt, you will not produce higher quality faster and sustainably and then you will blame Agile…
Requirements debt:
Over time many organisation build up requirements debt. Requirements debt is all those things we never have time for, or the bug list we never get time to get through, or the loooonnnggg list of customer requirements we just don’t get to deliver.
Paying this debt is extremely important; this is why you want to embrace agile, isn’t it?
However, one cannot pay requirement debt effectively if one does not pay both knowledge and technical debt first. In other words, if you pay knowledge and technical debt, then you will be able to pay your requirements debt as your bug list will reduce and not grow as fast as it did, you will therefore have time to deliver customer requirements, you will deliver faster yet your quality will not reduce etc…
Summary:
Any agile implementation is not about tools and recipes and process, it’s about people and the way they communicate and collaborate, paying your debt and most of all establishing a culture or habit of always looking for ways to reduce waste and improve as a team and organisation.
This takes courage, great communication, fantastic collaboration, trust between all involved, loads of effective feedback, a habit of breaking everything down to its simplest form and an approach of testing yourself and the way you work against the agile principles!
So, what is the essence of Agile then?
The essence of Agile in short is to do whatever it takes to establish an effective learning culture and to adopt an effective approach and implement complimentary tools to support continuous learning on your projects and within your organisation.
Accept the essence of Agile first, then the rest will fall into place and you will not lose the agile plot by focusing on tools, ceremonies, artefacts etc, but rather embrace all that to support your culture of learning in order to effectively deliver extreme business value!
Regards
Arrie van der Dussen
Agile Business Manager / Agile Coach
Kaizania
agile@kaizania.co.za