Last month we looked at the first five of ten key practices SAS has found effective in our ongoing adoption of agile practices. Let’s jump in and look at the next five.
- Provide coaching options. Great teams have great coaches. Give access to professional coaching as needed, and leverage the agile successes by sharing across teams. Good coaches have know-how but don’t necessarily tell how. Good coaches ask good questions. At SAS, we’re actively investing in a SAS Agile Coaching Framework to build our bench and our reach.
- Socialize, socialize, socialize. This one could be easy to dismiss, but is very important. Foster grassroots. Use online tools to build awareness, successes, and discussion on certain sticking points. At SAS, we have a large network of practicioners who trade ideas, as well as numerous online social-media resources. A word of warning: use discretion with this part of your communications plan so that it’s received favorably and with ongoing interest.
- Scale, creatively. We’re all a part of something bigger than ourselves, and even small teams align to larger portfolio of products. Look for opportunities to help teams optimize at scale. As example, use scrum of scrum meetings judiciously, not as a blanket rule. Be creative. Soften your terminology and gain buy-in by helping teams create a model they can call their own. Remember that teams can get more done better than any one team member. The official scrum guide published by founders Ken Schwaber and Jeff Sutherland recently featured an important change that helps make this point. In it, they noted the daily stand-up meeting should ask, “How am I helping the team?” vs. “What I am personally working on?” That's a subtle, but powerful difference.
- Close the loop. All of the investment in training and top-down support can fade unless there’s closed-loop feedback. Invest in agile tooling but give teams leeway in usage. Gather data and discuss what it means at team retrospectives.
- Have fun! Enjoy learning and adapting along the way! Agile has been shown to improve morale, satisfaction, and performance – even for teams and customers already working at high levels. Maintain and grow team engagement by spicing up routine practices such as iteration planning meetings and scrums. Encourage your team leaders to look for ways to keep agile fresh.
SAS is all-in when it comes to producing high-quality software that drives our business and our customer’s businesses forward. When applied well, agile supports those goals. I hope what we’ve learned gives insights that help your agile rollout too.
Tim
2 Comments
Nice to see that at SAS this hypes are also recognized. As it are the things:
- http://en.wikipedia.org/wiki/Scrum_(software_development)
- http://en.wikipedia.org/wiki/Kanban
Than I get puzzled for several reasons. As there are:
i/ The classic waterfall http://en.wikipedia.org/wiki/Waterfall_model has the same kind of stages as scrum. Could it not be better named as "stepstoned waterfall".
In that case the imbedded limitations would be more clear. Innovation and being real Agile is not a property of scrum.
ii/ that are the approaches of a manufactoring that have well defined goals and targets. It is optimizing to achieve these targets/goals where it is all about.
But what when you do not have those clear goals and targets? What are you doing in that case? I am sorry but I am missing some things on that.
That is in the first place it is so dificult to understand SAS products and an other is is incredible difficult to have SAS products getting aligned to common IT guidelines and policies.
For using SAS in BI Analytics field it is the same kind of questions. The situation source-data is not well defined should be researched first. The goals and targets can be changed some degree during the time working on it. All of that is not really suited to fixed way of working process.
This is different in the classic easy way of thinking having very well defined processes.
Thank you Jaap for your comments. Here at SAS R&D, we lean toward agile scrum vs waterfall. The primary benefits we see with scrum is that requirements are prioritized, implemented, and accepted in much smaller time-boxes (ie, sprints or iterations) than waterfall. Traditional waterfall tends to attempt to identify all requirements at the beginning. Agile gives us much more latitude in being able to respond to changing requirements, sprint by sprint. Innovation can happen spontaneously, but more often is a result of allowing time in a plan -- and agile encourages this in a number of ways such as setting aside time for research and compelling team members to engage at a deeper level.
To your point about manufacturing goals, indeed, there are some similarities. Agile and lean borrow several principles from modern manufacturing techniques. The dynamics of physical manufacturing is quite different than software development, in the sense that software design is relatively easier to configure and change sprint by sprint. This is why software firms tend to adopt the practices of scrum. The application of these practices is more of a journey, and we provide a number of support systems such as training and coaching to help teams mature their level of practice and results. I'd like to put you in touch with someone here about your BI Analytics comment so if you have other questions or would like to chat, feel free to email me directly at Tim.Arthur@sas.com. Thanks again!