Before anyone wants you to make an app for them, make sure they watch this video:
Karen and Sam from Growing Agile give us a runthrough on how antipatterns sneak in over time, often with the best of intentions with some examples:
WHAT: Burndowns updated by Scrum Master.
WHY: This antipattern features in many a team but if you do it, you own it. But who cares about the status the most? The team should, so it is best for them to own the burndown.
TRY: Don’t do it. Maybe the team will do it, it might even take 3 sprints, even longer..But the team need to fully understand their progress to do something about issues when they can fix it, rather then at the end when its too late.
WHAT:Same velocity every sprint.
WHY: Velocity should vary and should overall be going up.
TRY: Let the team know its ok to fail. Prepare management for failure. Commit honestly if you honestly believe you can do the work.
WHAT: Fines for being late to meetings.
WHY: You are giving people permission to be late.
TRY: When someone is late, don’t update them on whats happened in their absense, its their responsibility to find out what they missed after the meeting. Finish your meetings early to give people time to get to their next meeting. If people are continually late find out why.
We also discussed the difference between an antipattern and a problem. For instance a 45 minute standup is not an antipattern, its a problem.
For the remainder of the event we broke up into teams and discussed other antipatterns we found in our teams.
It was a thought-provoking evening and I really liked thinking about the differences between an antipattern and a problem. I also would use the format of WHAT/WHY/TRY again, its a good framework to use when thinking about issues.
We will be doing 2 last events for the year in JHB after missing a few meetings.
We have pinned down our next topic though which is sure to be a catalyst for some heavy debates.
Open spaces discussion on Scrum & agile topics you need help on
At SUGSA we have the opportunity to spend time with fellow Scrum and agile evangelists during events. During this event we would like to use the time to explore some topics you might need input into or advise on.
So who should come?
1. Those who what questions answered
2. Those who can provide input into our evangelists in distress
What is the format?
Topics will be proposed at the event. People will self organise themselves into groups to discuss.
Victoria Gate South
Hyde Park Lane
When? 30 October 2012
To register go to: here
At the October SUGSA meeting Peter Hundermark shared his views on how to lead self-organising teams, along with some honest experiences of his successes and failures and growth in understand as to what self-organisation actually means to how an organisation needs to change as a whole. The key to success seems to be in understanding organisations. Peter’s partnership with Dr Sigi Kaltenecker, a seasoned organisational coach, has led him to better understand organisations and organisational change. Over the years they have partnered to build a model for leading self-organising teams and the organisational change to support them. Peter touched a little on this model and on the classic examples of what self-organisation is about.
Some key things that stood out to me were:
- The reminder that any self-organising team needs a facilitator in order to work properly. This is to help avoid a single leader from surfacing and potentially dominating the team, destroying its self-organisation.
- Trust is a key factor – on all levels. Without trust it is hard to enable a self-organising team.
- Middle Managers need to become change agents focused on maintaining the change to allow self-organisation. The common scenario is that upper management and/or the development teams becoming deeply involved in trying to adopt the new agile way of working. Too often middle management isn’t focused on. However they are key in order to aid and promote the change. While we often succeed in giving a safe space for the team to fail – we too often don’t give that same safe space for middle managers to fail. As a result a lot of the transition doesn’t get supported in the middle of the organisation. In order to succeed with self-organisation – all levels of the organisation need to be supported and be able to fail and learn.
It was great to hear some new insights on self-managing teams – and to be reminded of the ones that we already knew. It was also interesting to get a taster of the model that is being taught by Sigi and Peter in their course.
We adjourned as usual for drinks and snacks afterwards – yet another SUGSA event enjoyably completed.
I have always enjoyed doing new and different things for Retrospectives. Believing that valuable retrospectives allow the team to truly reflect and improve.
A3 Thinking is a problem solving technique present in Lean which help solve problems at the organizational level.
Cara took us on a whirlwind tour of some concrete concepts used in Lean and Agile. Using the Deming model to illustrate that we do checking very well (retrospectives) and then Acting on it, but how often do we test and verify that the improvement goal are actually improving anything. A3 thinking applied to Team retrospectives help create testable hypothesis and keeps the system in mind.
Groups, Understand the Context
Cara introduced us to 2 companies, fictitious she assured us J. Each group was given 1 out of the 2 companies with their specific environment and current states. Knowing the context allowed us to study and understand the problem. The notes were extremely valuable and it was just the right detail to allow our imagination to fill in the rest.
We were encouraged to understand the problem and context but not to try and solve the problem, solving the problem was not the intention of the talk and Cara facilitated the problem solvers back to the exercise at hand.
We identified any factors that could increase the rate of change. These items are not positive or negative but to understand their impact on the rate of change in the system.
Articulate the current state (current problem) and the desired target state (long term ideal)
Write a hypothesis
Introducing a hypothesis creates the opportunity to make our goals testable.
“By [doing something] we expect [this result]”
Pass Conditions / / Fail Conditions
(if our hypothesis is right)
(if our hypothesis is wrong)
We can now test our goals at the end of the sprint to ascertain if the improvement goal is proving our hypothesis correct or not.
Using our imaginations and some guided “Real life” scenarios our group had a 3 week sprint, during the sprint we responded to all of the events and could say what our progress was on our retrospective goal.
We looked at what happened in the whole system. We tried to understand if our hypothesis was met proven true or false and we took that information to change some of the assumptions on expectations. We changed our expectations where needed and adjusted \ created new hypothesis to take into our next sprint.
Creating testable hypothesis, just testing it without worrying to get them right and understanding that the whole system has an impact helps us see problems differently. What Cara did was allow us to distill the essence of A3 thinking to an empirical experience that can be used by teams trying to kill some of their tougher impediments or at least understand the problem better. We now have another tool to add to a team’s toolbox.
Enjoy SUGSA events, want to get a bit more involved? Why not join next year’s committee? Nominations for the 2013 Cape Town SUGSA Committee, are now open to all SUGSA members.
We promise you dinner and drinks with international agile celebrities (when they come for our annual event), highly entertaining committee meetings, an opportunity to be part of a great team all passionate about building a great community, a chance to organise a world class events, your name and photo on our fantastic website 🙂
All we ask in return is commitment for 1 year to working as part of a team of 7 people to organise monthly events, an annual conference, a great website, and any other new ideas people have to enrich our community. You can expect to spend about 1-2 hours a week on committee business during normal months, with a peak of about 4 hours a week for the 3 months around the annual event.
If you would like to nominate yourself to be on the committee, please forward a picture, short bio, and statement about why members should vote for you to firstname.lastname@example.org before 21 November 2012.
After 21 November 2012, the list of nominees will be posted on our website, and voting will take place electronically leading up to the December monthly event. Each SUGSA member is entitled to vote. The committee will be chosen based on the 7 nominees who have received the most votes. The new committee will be announced at the December SUGSA event, and will be expected to perform committee duties from January 2013.
A technology company based in Cape Town is looking for a Product Owner to join their product department.
Working closely with a dynamic product management team, you will start by structuring and communicating a vision for your product and then testing this with various thought-leaders from around the organisation. Performing solid and pragmatic analysis into the business requirement is essential. This process will have you engage with each corner of the company, including Marketing, Sales, Call Centers, Legal and others.
Continuously showing real business value and prioritizing features based on ROI, you must find ways to reduce the time to market whilst still ensuring maximum quality.
You will be responsible for accepting or rejecting the software, and make the call if it is viable to be released to customers.
Driving the final testing, acceptance and adoption of the working software within the company is a key final requirement of the process.
Not only is this role within the software development realm, but you will be key in continuously challenging and changing the paradigm to provide better processes and solutions for staff and customers
Qualifications and Experience
- Tertiary education with a minimum of two years business analysis experience
- Experience in agile software development, especially in the Product Owner role, will be highly advantageous
- Experience in working with technology or software-based products
- Proven track record in project management
Duties & Responsibilities
- Structure and communicate a product vision
- Initiate a project
- Engage and represent various business stakeholders
- Set clear goals for the development team to achieve
- Create, groom, prioritize and order the product backlog based on real business value and ROI
- Facilitate incremental and continuous feedback cycle between the software and the business stakeholders
- Determine acceptance tests and facilitate the execution thereof
- Compile and distribute information radiators which show transparent project progress
- Retrospect and seek ways to continuous improve the introduction of new software into the business
- Provide leadership, motivation and challenge a development team throughout the software development cycle
Should you know of anyone in your network who may be interested, please contact tcoleridge(at)mweb(dot)com
We will be adding links to all the slides and videos from Code Lab in this post. Please bear with us as we assemble these.
Ideas Aren’t Precious, People Are: What we’ve learned so far at the Nordstrom Innovation Lab – Jeremy Lightsmith
Video’s shown in the talk
DEVOPS & Continuous Deployment – Len Weincier
Code is up on GitHub at https://github.com/
Hands on Agile Software Architecture and Design – Martin Cronje
Git Workshop – Kevin Trethewey
Unit Testing for SQL- Alain King
You want me to do what??? – Neil Zeeman
Fast Tracking GUI development – Herman Lindvelt
xUnit Test Patterns – Peter Wiles
Event Report by Pavel Dabrytski
I had an opportunity to attend Code Lab conference which took place 31 July – 1 August at Erinvale Hotel and Spa in Somerset West. And I must say it was great: great people, great topics, great venue…
But let me start from the beginning. This year the SUGSA committee decided to skip Scrum Gathering like last year and organise something little bit geekier. I was sceptical: tickets only became available one month before the event and the program was only finalized around the same time. But within matter of 2-3 weeks all tickets were sold out! How? Well, check out the topics http://sugsa.org.za/code-lab/
Most of the sessions were hands on, so a day before the event I prepared: installed necessary tools and packed my computer mouse and charger. But in fact during the event I was able to pair with other guys. Which I personally prefer, as this way I not only learn something new but also meet interesting people.
The biggest nightmare for the organisers was internet connectivity. When more than a hundred people tried to connect their laptops, iPhones, iPads (and whatever other devices people have invented) to the free Wi-Fi at once… well, it failed.
But let us go back to the event. There was mixture of local and international speakers (Jeremy Lightsmith and William Rowden). And there was something you don’t always see during such time of events: all the speakers were honest and open. They were open about their success and failures. These people really inspired the crowd! Have a look at this video for example, starring our international speaker Jeremy Lightsmith http://www.youtube.com/watch?v=szr0ezLyQHY .
Attending this event was a good way to stay up to date with new tools and new technologies. There was plenty of time during the coffee breaks to socialize and network. And after the first day many people stayed in the local pub for a drink. It was an opportunity to meet people with experience and who have already done their research, you avoid making the same mistakes in future.
I also came out of this event with a significant list of books I would like to read. This list will probably keep me busy till the next year.
Erinvale Hotel and Spa team was at their best too, making sure everyone has fresh coffee and muffins and delicious lunch.
So if you attended the event with me, I would like to ask you the question:
What will you do differently?
It was great hearing a product manager’s perspective on release planning and prediction. You don’t hear enough talks from product managers and the way they want and do things. Thank you Cliff Hazell for the talk and thanks to Unboxed Consulting for sponsoring the event.
#2 always gets promoted
I guess it depends how you look at this one. Who remembers Charles “Pete” Conrad and Alan Bean, the second guys to land on the moon? Sure I understand that you need to be second to become first. However what should you do when you become the president of earth?
That Steve Jobs quote about passion
Be passionate about your work, daily. If you lose the passion, you will lose yourself. I’ve started living this in the last year or two and it’s amazing. Frikkin love what you do, at work and at home. What’s the use you settle for anything less?
We learned that wordpress > twitter > facebook > linkedin. See some slides section below.
That Einstein quote about solving problems and thinking
This made me think about a quote one of my friends always says: today’s problems are caused by yesterday’s solutions. We need to think and react about things at a deeper level. We have to change our way of thinking to a systems thinking way. The fifth discipline is a good read about this.
The Japanese inspect and moer the hell out of things
Mura Muri Muda – Unevenness, Overburden (over working), Waste (non value added). Running at 100% isn’t great as it leaves no space for anything else. I didn’t get the just of this section as the late comers distracted me :/
Say no by default and force people to sell the value to you
Meeting = Massive waste of time
Implement No-Meeting-Mondays, slim down meetings and make them optional. Timebox it. Schedule meetings to end just before lunch time. I suppose this also depends on the type of meeting. Don’t make the daily scrum optional.
The sooner you get working software out, the better. Release often. Cliff mentioned that his company went from 4 releases per year, down to 4 releases per quarter.
Know where in the process you are at all times. This can be achieved by using processes and tools (because there is value in the items on the right)
Cliff uses Trello to track his product backlog and if I understood this correctly, Trello replaced the scrum or kanban board in his company
You are only able to predict what you know. He is able to predict with certainty what will be released within the next 3 months. He has a broader plan for the next 6 months, and that’s where it stops. Deadlines stays intact for 6 months He uses Liquid Planner to help with the predictions. There was a strong feeling from the audience that it’s a gantt chart. However Cliff has made it work for them. Inspect and adapt I suppose?
Strip down the product backlog as much as possible. If something is on it longer than 3 months and it hasn’t been started, bin it. If it is important enough, it will come up again. You will spend all your time grooming and too little time developing if you have a massive product backlog
You always need to get buy in from management. If you don’t have it, you are wasting your time. Cliff gets the execs involved in the prioritization part of the process. After this the teams can get going with minimal interruptions
Cliff mentioned that it’s better to do changes when it is cheap and early in the process rather than later in the process where an entire feature needs to be undone to cater for something else. In a way this sounds to me like bad architecture. My opinion is to think things through and build systems as generically as possible. Any change should then be easy.
Some one-liners here:
People is more important than process.
Share metrics with the teams. They need to see what the execs see as well. Show it live if possible
Know your customers and people working for you. Do happiness surveys on staff and customers. I’m reminded of a niko niko calendar here
Happy teams do great work.
If it’s rotten at the bottom, someone screwed up on top
Focus on the long-term rewards. What you do needs to be rewarding.
Gerald M Weinberg, check out his retro website. Not sure which book Cliff referred to, however on a quick search it looks like these are his more popular works:
- Understanding the Professional Programmer
- The Psychology of Computer Programming
People ware — Productive Projects and Teams (ISBN 0-932633-43-9) by Michael Lopp. Cool intro on Michael’s site
Drive – Dan Pink
There was another book he referred to, called meeting creatures I think, I didn’t get the author though. Cliff also mentioned something about churn- the silent killer. Could you please give some clarity on this?
Rework – 37signals
The Fifth Discipline – Peter Senge
for kanban / scrum board
Very gantt charty, however they’ve adapted it to help predict release dates and it’s been working well over the last 6 weeks.
Some slides graphics
These are my opinions and observations only and not necessarily correct.
Peace and love and happiness