RSS

Tag Archives: Agile

Scrum Thoughts

I’ve just spent the afternoon reading the updated Scrum Guide from Ken Schwaber and Jeff Sutherland.

There are some great points in it – some of which I have recorded here because in my experiences working with the various agile teams that I have met over the years it is good to have a reference point for some of the key things that I have noticed not working correctly, but are being done in the name of Scrum.

“Scrum recognizes no titles for Development Team members other than Developer. Regardless of the work being performed by the person, there are no exceptions to this rule; “

I like this – it is not the “developer” definition in the sense of a developer being someone who writes code, but a developer is someone who contributes to the development of the product. This has been used and maybe even abused in the past where teams consist of only programmers, rather than a cross skilled group of “developers”. We need to think about the skills needed in the team and the proportion of those skills, and what work is required to be done to complete the task as opposed to the titles of the team members.

“each event in Scrum is an opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to insect and adapt.”

This one is a good one too – how many times to team decide to not do something because they don’t see the value and then head off down the wrong path. I was recently speaking to a group who does not do Showcases at the end of an iteration – why not? The extended team did not want to attend….what a missed opportunity and a “failure” according to the Scrum guide.

“Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.”

This will challenge a lot of people’s thinking, particularly those teams who are tending to do incremental delivery of a predefined product, not looking at each interation as a separate activity that needs to be planned and actioned appropriately. I said something similar to this in a training session lately and almost everyone in the class gasped….until I explained the concept, then they all said “yup – that makes sense” (phew!).

“The Daily Scrum meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.”

How often do we hear of Stand-Ups being extended for the longer period. Meeting still need to happen but the standup or Daily Scrum is so important for this synchronisation and planning actions – teams that are dysfunctional and don’t understand the need for the stand-up or do them poorly often don’t have this coordinated view of what needs to be done by the whole team!

Advertisements
 
Leave a comment

Posted by on August 5, 2011 in Agile

 

Tags: ,

Splitting stories and exploding scope in agile projects

We used the  “Abstract to concrete” approach to splitting stories in a training course recently.The approach is published in our “resources” page, alongside some other approaches that also work.

But I told the class I would publish it here for easy reference, so here it is.

008

Read the rest of this entry »

 
1 Comment

Posted by on July 2, 2011 in Agile, Business Analysis

 

Tags: ,

‘Soft’ skills or dealbreakers?

A few weeks ago the Australian sales team headed down to Sydney to attend Agile Australia 2011. They had a busy couple of days meeting and talking to Agilests from all over the country and noticed a common theme. Lots of companies have adopted the practices of Agile without accompanying them with the necessary cultural shift that they needed to make things actually happen. Anyone working in software development will have heard that story before and it always makes me wonder why we still use the term ‘soft skills’. Soft skills are not a small, unimportant or unnecessary thing to consider, they are the crux of your organisation’s ability to succeed. If you can’t talk to people, listen to them and work together you’ll never get anything done!

With regards to Agile, in order for projects to be successful you need support from your business and investment in training and coaching so that all staff members come along for the ride. The processes of Agile and Scrum are important, but without understanding why you are following these processes it’s going to be almost impossible to make anyone do them (which is the reason SoftEd’s Agile training courses focus on awareness as well as process).

What else did they see at the conference? First of all keynote speaker Alistair Cockburn talked about Agile UX Design as an ‘up and coming’ area of interest. They listened to Rob Thomsett‘s presentation on whether your business is ready for Agile According to Rob, “implementing Agile practices is a disruptive cultural revolution” and Agile business models are based on simplicity and transparency. Daniel Oertli, who has made big changes at REA Group, promoted the value of planning (not plans necessarily, but the actual planning process) and of being customer centric rather than customer driven (an important distinction I think, after all you can’t and probably shouldn’t do every single thing that every customer requests, but you need them at the heart of your organisation to make sure you’re going in the right direction).

According to Michael Bromley Agile isn’t the point, better is the point, and his organisation (NBN-Co) believe that Agile is radical and will take time to develop, but the only way to make this happen is to get started and go for it because you learn Agile by being Agile. Just as you learn, fail and improve in Agile projects you must learn, fail and improve at doing Agile itself, “Agile is a way of thinking”.

There were a few other things you see at most conferences nowadays: panel discussions, game playing (the marshmallow challenge) and the usual buzz-word bingo (everyone has their favourite terms!) which keep us entertained over the two days. Thanks Agile Australia!

And just one last thing, we at Software Education run conferences as well: SDC, focusing on business analysis and Agile and STANZ, our testing conference. We are really proud of the calibre of international speakers who present at these events and the high quality of the event, the material and the discussions which is always reflected in the feedback we get so if you’re interested in coming along, or want to know more about us in general please go to www.softed.com. Thanks!

 
Leave a comment

Posted by on July 1, 2011 in Agile, Culture

 

Tags: , , , , , , , , , , , , , , , , ,

SoftEd runs a course in Israel for M86 Security

Software Education is delighted to announce that we are delivering our Practices of Agile Teams training course for M86 Security, the global expert in real-time threat protection and the industry’s leading Secure Web Gateway provider. Our chief knowledge engineer Shane Hastie is flying to M86’s R&D centre in Tel Aviv, Israel in July to deliver the Agile course and will then go on to M86’s offices in Orange County (O.C. ) in California to provide some consultancy services, following on from training he delivered to the O.C-based team last year.

This will be the first time that SoftEd has delivered a course in Israel, although we have always had a global reach with courses taking place in the U.K. and U.S. as well as Australia and New Zealand. We are proud to see that yet again knowledge from ‘down under’ has such influence across the world! M86 Security are a global organisation and our ability to work with them in Israel, the U.S. and New Zealand is a testament to our dedication to providing our customers with a tailor-made solution for their training requirements. Shane first gave a short Agile tutorial to the M86 Security research and development team in Auckland, which lead to more training for their New Zealand team and then the opportunity to work with the team in O.C., culminating now also with the trip to Israel. Thom Linden, SVP of Global Research and Development at M86 Security said, “To make a successful transition to Agile, training and coaching from experts, who have the right combination of knowledge and effective interaction skills are extremely valuable. SoftEd has achieved great results in mentoring our development teams to adopt practices and tools to successfully apply Agile in our business.”

Shane is looking forward to this trip, which adds to what has been a busy and exciting year for him with not only several training and public speaking engagements but also with his work with the IIBA defining the Agile Extension to the BABOK (Business Analysis Body of Knowledge). He is the only Australasian member of the committee developing BABOK version 3.0. Shane will also be speaking at Agile 2011 in Salt Lake City on 8 – 12 August with Steve Adolph.


M86 Security is the global expert in real-time threat protection and the industry’s leading Secure Web Gateway provider. The company’s appliance, software, and Software as a Service (SaaS) solutions for Web and email security protect more than 25,000 customers and 26 million users worldwide. M86 products use patented real-time code analysis and behavior-based malware detection technologies as well as threat intelligence from M86 Security Labs to protect networks against new and advanced threats, secure confidential information, and ensure regulatory compliance. The company is based in Orange, California with international headquarters in London and development centers in California, Israel, and New Zealand.

Software Education are internationally recognised for their expertise in software development training. With over 50 different course titles in Business Analysis, System Design, Programming, Software Testing, IT Management and Agile Development, Software Education not only provide access to leading-edge content but also to an unrivalled network of international experts.

Whether through Software Education’s public courses, individually tailored in-house training or our international conferences, STANZ and SDC, you will acquire practical, relevant skills which you can use immediately or work towards certification.

 
Leave a comment

Posted by on June 21, 2011 in Agile, Courses

 

Tags: , , , , ,

Learning from Baboons

I’m sitting on a plane flying from Wellington to Melbourne, and find myself urged to write this blog post.

I’ve just watched a National Geographic video called “Stress. – Portrait of a Killer” that I found really fascinating. It looks at research that has been conducted over the last 30+ years into where stress comes from and how it impacts us.

Stress related illnesses have a huge impact on our society today, and together make up the majority of the illnesses that kill people before their time.

I knew that, and was at least somewhat aware of a lot of the material presented in the documentary.

What leapt out at me were some of the conclusions, and a piece of research done by Robert Sapolsky.

Over 30 years he has followed a number of troops of baboons in the Serengeti and found typical baboon behavior (hierarchy driven, top-down, might-is-right, to win you need to beat everyone around you, etc.) which is equated to the behavior seen in many hierarchical human organizations; the documentary talks about the Whitehall Study that show the same stress responses in 20000+ civil servants in the UK as found in the baboon studies in the Serengeti.

Sapolsky recounts the story of one particular troop of baboons that suffered a tragedy about 20 years ago – illness wiped out all Alpha males in the troop along with many others. The animals that survived were the ones who were more cooperative than combative, perhaps it was because the “nice” baboons were the ones who would be cared for by others when they fell ill.

The fascinating thing is that this troop of baboons went on to become a grouping of “nice guys” where collaboration, grooming & feeding each other and supportive behavior is now the norm. When new males join the troop they bring with them their old hierarchical habits and it takes about six months for them to learn that “that’s not the way we do things here” and to fall in with the cooperative behavior.

Part of Sapolsky’s research involves taking blood samples from the baboons and he has found a significantly lower level of stress hormones in the cooperative baboons than in any other troop he has studied over the last 30 years.

He goes on to suggest that human beings could learn from these baboons and create a better society, in which collaboration, autonomy and cooperation are the norm, and as a result lower our stress levels and improve both the quality and duration of our lives.

Being a staunch Agalist I found this speaks to my fundamental beliefs about why Agile practices work – an Agile team is a collaborative environment, where people support each other and all “win” together, rather than competing for power and privilege. Certainly it has been my experience that effective Agile teams are nicer places to work, with generally less stress and greater levels of happiness.

What do you think – am I just an idealist, or can we turn our organizations into happier, more productive places?

 
2 Comments

Posted by on May 8, 2011 in Agile, Culture

 

Tags: , , , , , , ,

Why so little good Agile?

Today I gave a talk at the  Government Test Professionals Forum conference in Wellington.

I presented a case study about how the Farm Systems Division of Livestock Improvement Corporation have adopted Agile methods.
I told the story of Team Awesome (they choose the name themselves), how their practices have changed and the measurable benefits that have resulted from their new way of working:

  • Massive reduction in residual defects
  • Increased team satisfaction
  • Shorter time to market
  • Increased customer satisfaction

I told the story of how the team collaborates, how all the roles work together. How testing is fully integrated into the flow of work and how the whole team (developers, analysts, product manager, testers) coordinate their activities starting with expressing the detailed requirements for user stories as test design specifications using the Behavoural Driven Development model. They have adopted Agile well, and gained the benefits that all the books talk about.

After the talk I was chatting with one of the attendees and she said that my story was unusual – her experience as a tester on “agile” projects has been uniformly negative – testers as victims of development teams who use “going agile” as a excuse for hacking and not bothering with requirements.

This saddened me; surely we know how to apply these practices properly, don’t management in our organizations understand that agile is about applying the practices in a disciplined way, you can’t just pick the pieces that seem easy? Agile works when the combination of practices are applied together – for example: user stories are a good technique for identifying features and prioritizing the work to be done, but they must then be supplemented by some technique to define the detailed requirements on a just in time basis, just ahead of when the story will be developed. You can’t just adopt user stories and ignore the detailed requirements and testing – that is truly Tragile, but seems to be oh-so-common.

Building software is hard work; building good software takes a concerted team effort, irrespective of the methodology being used. We know this, and have known this for the last 40 years.

Please stop calling these half-hearted implementations Agile – it’s not, it’s just a continuation of the bad practices that many organizations have followed over the years, just with a different brand.

 
1 Comment

Posted by on May 3, 2011 in Agile, Testing

 

Tags: , , , , , , , , , ,

Advanced Agile?

I was at an Agile Academy Meetup last night and the topic was “The Agile Journey and beyond”. It was great to hear about the agile concepts and practices being applied, in real world scenarios – small and large organisations. But it was equally great to hear about how these organisations were using agile in the way I think it is meant to be used – not as a rigid framework, but as a guideline for an approach. All three of the speakers made a comment like this (please note that I am paraphrasing here) ….”We tried XYZ and it worked for a while, then it stopped working so well, so we changed it”. I had to giggle when Adrian said they sit down at their standups….because they use a webcam and it is not viable to standup. Another speakers said “we tried the 3 questions at the standup, but it did not work, so now we “walk the wall””. I was really excited to see this extension of agile practices and acknowledgement that the practices that we see, read about and talk about so widely are totally malleable and able to be modified to suit each and every organisation. But there is a gotcha! All of the modifications came as a result of trying the “proper” way of implementing the practices, and then careful and comprehensive understanding of what about the practice did not work, and why, and then careful and incremental changes to the practice to make it work better. It was described best by one of the speakers as “an agile implementation of agile”.
So I was wondering:
1. is taking the agile practices and modifying them a good indication of agile maturity?

2. which practices are the riskiest to change and why?

3. how long should you try the “proper” way before considering change?

4. is modifying the practices a sign of agile maturity of advanced agile usage?

What are your thoughts?

published by Sharon Robson

 
3 Comments

Posted by on February 23, 2011 in Agile, Culture

 

Tags: