Good article on sleep and productivity – you need at least 6 hours per night to not fall into a vicious cycle of lower productivity leading to longer work hours, less sleep, and then lower productivity.
The Agile Manifesto asks us to work in such a way that we can maintain our pace indefinitely.
I’ve just finished the first complete draft of my book Scrum Insight. Find out more here on my LinkedIn post about the book…
“Business engagement alone is a necessary but not sufficient condition for Agile to succeed”
It’s taken a while but now it’s well understood amongst seasoned Agile practitioners that Business engagement is necessary for successful Agile implementations. Just when we thought engaged Business owners were enough, we’re now realizing Business engagement alone is not sufficient. The impact of corporate shared services, especially Human Resources (HR), on Agile adoptions or transformations are often overlooked. In fact, Agile practitioners often bypass HR in their zeal to quickly change the way they work and the related people processes.
“Companies are running 21st century businesses with 20th century workplace practices & programs”
– Willis Towers Watson
It’s not just IT departments practicing Agile but 21st century businesses overall that are characterized by flatter organizations and an insatiable appetite for small ‘a’ agility. Agility that is pushing and breaking the envelope of current HR processes and tools. Agile individuals and teams are very vocal when it comes to calling out technical obstacles in their way. The same could be said when it comes to HR related obstacles that impact Agile individuals and teams. If we listen, here’s what we would hear:
As the volume increases, how will HR and HR professionals respond?
“2016 will be the year of Agile HR … most HR teams have no clue what Agile HR means”
– HR Trend Institute
The reality is that most HR teams have no clue what Agile is, never mind how it will ultimately rock their world. Most Agile initiatives emerge from the grass-roots or are driven independently by IT functions with little to no involvement from HR. HR sits on the sidelines and watches IT “do their thing”. There is a misconception that Agile exclusively falls under the IT domain; overlooking the fact that the core of Agile is about the people and culture – the sweet spots of the HR profession.
There are three significant change movements gaining momentum:
All three have the common denominator of people; an integral part along the entire timeline of each movement. As these three movements overlap – at the intersection – will be HR. So, who better to help navigate the emerging paths of each change than “the People’s people”?… otherwise known as “HR”.
An analysis of the Human Resources Professionals Association’s (HRPA) Competency Framework shown below can help guide which HR competencies will have the greatest impact (on a scale of 1 to 10) on Agile.
“How do we get HR started towards their destiny?”
If you’re an Agile team member, invite HR to start a conversation about what Agile is and how they can help you and the team.
If you’re an HR professional, here are some suggestions:
To help HR take the first step, here are some suggested Agile learning resources:
It’s time for HR to get off the sidelines and get in the game. HR needs to be a “friend” to Agile, not perceived as a “foe”.
Borrowing from a Chinese proverb,
When the winds of change blow, some will build walls while others build windmills… the harnessing of your greatest natural resource, your people, into power.
Build windmills.
I just read a great article Impressionism: Go ahead, try to predict life. You’ll fail
Enjoy!
Two weeks ago I joined a temporary team of Scrum Alliance Certified Scrum Trainers and Certified Enterprise Coaches. It was a fabulous experience and I hope that I will be able to do it again sometime soon. We worked together to build real valuable results for the rest of the Scrum ecosystem including reference training modules and in-depth website content, feedback for Scrum Alliance programs, and even some fun videos.
Brock Argue was one of the CECs there, and he has written a great summary of how it felt: The Art of Teaming Part 1. One cool point he makes:
Introductions were friendly and helpful and as we started getting into the work things heated up…. I got frustrated with the direction of the conversation and I grew impatient with the lack of progress we were making. I’m sure other team members were experiencing similar feelings, and as coaches we understand how difficult team formation can be. Imagine how unsettling this is for a team who isn’t aware of these group growth stages; that they’re unavoidable and healthy to experience.
The stages Brock is referring to are the stages of team development as described by Tuckman: Forming, Storming, Norming, and Performing (and sometimes Adjourning is added on).
Thanks to Robin Dymond, Mark Levison who organized the event and Shannon Carter from the Scrum Alliance who supported the event with her personal presence.
This is a good reminder: change can be fun or exciting.
Change isn’t always bad. To add my own opinion to Mike’s excellent post, change is how we grow. If we don’t change, that is death. It is stasis that we should fear!!!
From Mike’s article:
If you are a person who helps others to embrace or live through change (whatever your interpretation of change is)….
… consider the damage you are causing by inspiring fear where it simply may not be appropriate or necessary.
Buy it! You won’t be disappointed!
I read the book in 3 sittings.
Zuzi gave her book to me in October. She was visiting Toronto at the time and we spent a few days together teaching Scrum – I was honoured that she would share a classroom with me and that I’d get a sneak peak at her new publication. Almost immediately after she gave me the book I found a few minutes to thumb through it and read the foreword and first chapters. I immediately liked what I saw.
The foreword is written by Linda Rising who frames the book nicely by reminding us of these simple principles: “successful change is built around small steps and learning”, and “the book offers a chance for reflection and evaluation”. Zuzi’s preface describes briefly her journey to become a great Scrum Master. Hers is a story about humility and studious peristence; the journey is unique and difficult for us all. I could relate! The best aspect of the early pages in the book are the photographs of Zuzi. The book exudes her character traits: a friendly and insightful expert, a colleague and advisor. Her photos, as well as her illustrations throughout the book, help the reader to understand her colourful character; her stance as a coach and mentor; and her voice as an author.
My time was limited so I didn’t get far in that first sitting though my first impressions of the book are memorable. It’s a big book – not thick, that’s not what I mean. I mean large, wide pages. Approximately 20 centimetres square. It’s the kind of book that lays open on a coffee table. This is important! I understand many people buy digital books but if you can find the book in physical format, buy it! The medium is the message, as Mcluhan said. The medium, in this case, is a lightweight book that rests easy, open-faced, on a desk or coffee table. As you pass by the table or sit for a while to enjoy a conversation, you’ll find the book open and waiting for you. You’re likely to thumb through it lazily, your mind wandering while on the phone or talking with a friend, then something will catch your eye. It’ll be a page you’ve looked at a dozen times but suddenly a sentence or illustration will stand out for you, draw your attention. Like, “…if you join a discussion with the core metaskill of curiosity it will be different than if you choose listening or teaching”. That sentence is on page 88 – that’s the one that jumped off the page for me today. I’ve read that page a few times already but this day, in this moment, that sentence resonates. Such a simple sentence on a page and sparse text and white space…but exactly the solace you will need.
I was riding a train with the book open on my lap. Through the window passed the Canadian landscape, and I’d glance at the book between sips of coffee to take in another paragraph, picture, page. (See how cool the format is??) What I’ve learned from the next chapters of the book is that I share Zuzi’s interpretation of Scrum and of the Scrum Master’s role.
Her perspective is a philosophical one, yet she effectively relates the material to practical examples. Zuzi describes a concept she calls the #ScrumMasterWay. This is an innovative model for understanding how a Scrum Master can adapt their mode of service depending on the conditions of the organization they serve. Perhaps at first, the organization they serve is ‘A Scrum Team’ – and in that mode of service a Scrum Master will facilitate Scrum and help the team to self-organize. Next, after all the easy fruit has been picked and the Scrum Team is capable of continuous and deep self-improvement, the Scrum Master’s mode of service is likely to change – the team no longer needs help with the rudiments so the Scrum Master may focus more intently upon relationships to and within the team. And finally, the 3rd level of #ScrumMasterWay is achieved when the Scrum Master is able to focus their effort toward the entire system, “bringing the Agile Mindset and Scrum values to the company level”.
Reading about Zuzi’s #ScrumMasterWay concept in the previous sitting led me to think nostalgically about my own journey. I know this book, had she written it a decade ago, may have saved me from some mistakes of my own. I’ve come to more deeply appreciate her telling of the Scrum Master role.
In the 2nd half of the book, she provides a glimpse into numerous related practices and concepts. A collection of references and teaching tools that most Scrum Masters will discover along their journey. For example, all Scrum Masters will find themselves in discussion with stakeholders about the nature of complex problems and, ta da!, like a stone tablet from a high mountain will appear Dave Snowden’s CYNEFIN framework! A simple diagram…it’s so obvious! All Scrum Masters will find themselves in a personal struggle between telling and listening: “should I coach as a teacher?” or “coach as a facilitator?” and, without fail, a fellow Scrum Master will recommend a training course with the Agile Coaching Institute to better understand the coaching stance(s).
Here’s the truth of it: if a young jazz musician wants to become a great jazz musician, there are some iconic recordings to which they must listen: Kind of Blue; anything by Duke Ellington and Louis Armstrong; Blue Train; Saxophone Colossus. No drummer is worth their salt without having spent a zillion hours listening to Max Roach and Jimmy Cobb. Likewise, every great Scrum Master has had to grapple with the iconic challenges of servant leadership – they’ve spent a zillion hours pondering the difference between the words “should” and “could” and they’ve praised the power of the question, “what if?”
So, to help Scrum Masters along their journey, Zuzi has compiled many of the community’s greatest hits in her book. Einstein is often quoted as saying, “If you can’t explain it simply, you don’t understand it well enough.” Perhaps then, one can examine how well a person understands a concept by how simply they can explain it… right? By that measure, it’s evident that Zuzi understands her material as she’s able to distill complex topics to just a colourful drawing and a few bullet points. “Root cause analysis” is described concisely with 3 paragraphs, 4 bullet points, and a beautiful drawing of a tree. Her purpose, keep in mind, isn’t to make the reader an expert in root cause analysis – her point is as if to say, “remember…problems often run deeeeeeep in the system. They’re organic. Find the seed.” I’m hearing in my mind a wise old music teacher, telling the aspring young jazz musician, “remember Herbie Hancock…go listen to Maiden Voyage…behold the deeeeeeep groove and floating melodies. It’s organic”.
The collection of materials which complete her book include highlights of Tuckman’s “Stages of Group Development”; Lencioni’s “Five Dysfunctions of a Team”; the martial artist’s progression through “Shu Ha Ri”; a shortlist of “Powerful Questions”; and a few others. In this last sitting, as I finished reading the book, I was struck by the similarity between Zuzi’s journey and interests and my own. I too have enjoyed Lencioni’s books, Tuckman’s model, the practice of co-active coaching. While I’ve lived and practiced all these years in Canada and Zuzi has lived and practiced in Prague, how is it we have been exposed to a similar body of knowledge and wisdom? I take some comfort in that, actually.
I face a difficult decision now. Zuzi signed this book for me and it’s in pristine condition. However, if I’m not careful, I am certain in the coming years this book will become littered with notes and comments, dog-eared pages and sticky-notes everywhere. Shall I allow myself to ruin this pristine book? Yes. Yes, I shall 🙂
See also:
I facilitated this workshop today for a senior leadership team. I mostly employ famous quotations familiar to many to provide a brief overview of Servant Leadership as well as a learning framework for systematically building capacity in others while improving the systems in which they work. The folks in the workshop seemed to really connect with Scott’s CLEAR model (not so famous but ingenious in its deceptive simplicity). I offer it as a guide for designing CLEAR acts of leadership.
Many times, participants in Certified ScrumMaster or Certified Scrum Product Owner courses ask about automation testing for agile development.
The article which follows provides an excellent answer to one of the most popular questions. After reading it, please consider leaving a comment below.
By Agile Zone
Agile automation testing is particularly important in the Agile development lifecycle. Agile software development involves a constant feedback loop among team members. This is in contrast to the Waterfall model of development, where software testing only begins once the development phase has been completed.
In Agile development, software testing activities are conducted from the beginning of the project. Software testing is done incrementally and iteratively. Automation testing is an extremely important part of Agile testing. After each change in the system, it is important to run a battery of automated functional and regression tests to ensure that no new defects have been introduced. Without this automation testing harness, Agile testing can become very time-consuming. This can result in insufficient test coverage. This will, in turn, affect software quality. Automation testing is necessary for the project to maintain agility. As a matter of fact, introducing automation processes such as automation builds and automation smoke tests is important in all aspects of agile development. As budgets shrink, time spent on repeatable automation testing becomes more and more necessary.
Continue reading here.
I have yet to find a better article than this one on transitioning from Waterfall to Agile.
By
Agile is designed to promote positive and functioning relationships among team members, enabling self-administered teams and team processes that address the continual consumer demand for updates and the fluctuating levels of software consumption. Teams integrate multi-talented resources into cross-functional process to boost production and inspire innovation.
Agile methodologies allow assessment of project direction throughout the entire software lifecycle. The strategy of regular iterations incentivize teams to produce potentially shippable output at the end of each incremental build, providing immediate opportunities to redirect objectives for quicker and more continuous delivery. In this way, software development can happen while requirements and analysis are occurring. Development is integrated into fact-finding through the build activity rather than strictly defined as stages of production.
Continue reading here.
I recently came across an excellent article on how teams are taking the best of several Agile methods and combining them together into a solution which works in their specific environment.
The overview and description of the essence of Agile, Scrum and Kanban is really helpful.
After you have a chance to read it please share your reflections in the comment section below.
by
If you have any issues with the methodology approach you have in your company, then you have probably heard these words already. That is our case as well. At a certain point in time, we felt like we were no longer facing the rapidly changing requirements that come from modern world business and that the software development methodology we had was pulling us back….
Continue reading the article here.
“Each week there are more and more exciting items to share with our ever-increasing newsletter subscriber list of leaders who, like you, are creating positive change in organizations across Canada.”
Rachel Perry, Content & Community Coordinator
Recently we sent out a newsletter with some really great announcements! Here is a snippet from the weekly REALagility newsletter.
“Not only do BERTEIG coaches have fantastic insights to contribute to the advancement of the Agile industry, but also our Learning Events – for CSM, CSPO, CSD, SAFe, or Leadership – in both Toronto and Vancouver – continue to expand. In addition, multiple avenues for offering encouragement and support in a variety of ways are opening up all the time.
If our weekly newsletter were to include all the news, it would be 100 pages!
Sure, that might be a bit of an exaggeration but, truth-be-told, instead of putting EVERYTHING in the newsletter we share just key highlights, along with a warm invitation to hop on over to the Agile Advice blog where more knowledge, announcements and entertaining posts can give you plenty more details than what can be expressed in a weekly communication to your inbox.
We are excited to share that last month Agile Advice was viewed 18,000 times. Not only will you find more articles posted than ever before, but you will also discover a new development on the World Mindware page on Agile Advice; detailed accounts of hundreds of positive statements about BERTEIG’s coaches who are some of the leading Agile coaches in the world.
This week we featured Agile Leadership coach, Michael Sahota, on
Agile Advice. In September, he will be presenting training for the Certified Agile Leadership (CAL1) training in Toronto. He was the second person to receive the designation to teach this class and the first to offer the training world-wide. He will also be offering a webinar this Wednesday, 24th Aug – register here.”
If you haven’t signed up for our weekly newsletter yet, I encourage you to consider giving it a try.
My bias for Martial Arts-related Agile metaphors shows up again in this list of three links for agile leaders, developers, and carriers.
All are listed on The Pragmatic Bookshelf.
2. The Indispensable Developer
3. The Way of the Agile Warrier
Did you know that according to the Scaled Agile events page (http://www.scaledagile.com/event-list/) BERTEIG is offering over 80% (17/21) of SAFe classes in Canada between now and the end of 2016? And did you know they will be offered in seven different locations?
These SAFe classes are offered in Toronto, Vancouver, Montreal, Ottawa, Waterloo, Mississauga and Markham!
You can register here for upcoming course offerings.
“Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future,” David Sabine
My name is David Sabine. I’m a Real Agility Coach and have been thinking about what Real Agility means to me.
My introduction to Real Agility began in 2007 when the CTO of the college I was working at in Fort McMurray, Alberta brought in Mishkin Berteig as a third party consultant. Back then, I was a software developer and what I experienced then is still true today. The value of bringing in a third party to solve business challenges is immeasurable.
Time and time again, as I have been involved with companies, either in a training or a consulting capacity, I have found that a third party presence provides or creates a break-through. The purpose is not that I go to a company as a consultant and I bring my new ideas, as though I am the only one with new ideas. What happens instead is that I visit a company and my presence, as a coach, opens the door for the internal staff to explore their own new thoughts, or concepts or possible solutions. So the ideas that are already in the company are just allowed to blossom a little bit in the presence of a third party,because this third party allows or creates a sense of permission, a sense of autonomy for those staff. They’ve been invited to explore concepts and they’ve been invited to think through their business problems from a different perspective and I am there just to reflect what they already have or what they already know.
That occurred when Mishkin Berteig visited the college in 2007, and that occurs every time I go and visit a company for training or consulting.
To really understand what Real Agility means to me, I’d like to tell you about how I came to software development in the first place beginning back in 1993 when I was starting university and was a freelance musician.
I had two passions at the time: the pursuit of music and the logic of programming. My computer tended to pay the bills, more so than being a freelance musician, so as a career path I guess I was drawn to software development and started to build my own products early on in 1996-1997. I was writing software for small business clients with the aim to eventually build a product on my own and release it for sale worldwide.
In 2000, I started to develop a product with a friend of mine. In 2001 we released it to other developers in the world. Our first sale of that product was in Belgium and for the next few years it sold worldwide. We had about 2000 websites that were using our product and it was translated into seven different languages by the community of users. It provided my friend and I with a reasonable income and a great opportunity. It was fun!
In 2006, I realized that my own growth as a computer scientist required working with others beyond this friend, to work in a team, in fact. I moved to Northern Alberta and worked in IT department for a college. As I mentioned, in 2007, the CTO, brought in Mishkin Berteig to provide us with a 3-day training course on Scrum. Quite immediately I loved it because I could see how it would provide us with a lot of opportunity to solve problems we were facing in an IT department and, secondly, it just seemed like a more human way to work. I was reflecting on all of these periods I had had as a musician, working with other musicians, and it just seemed like a better way to approach the creative endeavor than other project management methods that were in play at the time.
Since that time, I’ve been practicing them in a variety of settings and I’m more convinced now than ever that the Agile Manifesto provides us with a great solution space as we respond to business challenges. Recently I’ve decided not to be a developer or product owner but have decided to join Berteig full time and train and coach other teams.
So that’s the story of my personal evolution. My personal journey.
Looking back on that training I can see how I felt immediately that Real Agility was an alternative way of doing things.
I studied music since I was a child and music has always been a huge part of my life,and as a musician, one becomes aware of or familiar with continuous improvement. This is the same concept found in Real Agility. But with music it’s incremental, tiny, tiny increments of improvement over time. We respond to an audience. We respond in real time to our fellow musicians. We are always taking in input and that informs our performance of the music. As musicians, we spend a lot of personal time developing our craft. We spend significant time in performance so we can receive the audience feedback.
What I mean to say is that musicians are excellent examples of high performance teams and are excellent examples of creative excellence, who understand tactical excellence and what it means to get there.
When I joined Software development in a large, bureaucratic institution – the college – it was anything but natural for me. At that time, I was more than just a software developer. I was systems analyst, database admin and a variety of positions or roles. It just felt like an industrialized, mechanical environment where people were expected to behave as interchangeable units of skill. Work was expected to get done in the prescribed procedure. And decisions were expected only to be made by the smartest or the highest paid few and if you weren’t of that ilk, you were not expected to behave autonomously. You were expected to be just part of the machine and it felt very inhuman, as most people feel as a part of a large hierarchical bureaucracy.
When Mishkin facilitated the Certified Scrum Master training course in 2007, it just blew all those doors open. It reminded me that we can approach our work the way I had naturally approached it, as a creative individual who is capable of learning and wants to receive immediate feedback from audience or user, and who can make autonomous decisions about how to apply that feedback into the continuous development of software and systems and large infrastructure.
These business challenges are pretty common. They are delayed projects or projects that that blow the budget, or where a group of people are assigned to the project and they can’t possibly complete the scope of work in the time given. Or staff are demoralized, and how that expands through enterprises. There are many examples. The college where I was working suffered all of the most common issues and the one that hurt me the most or I felt the most was attrition. Dis-engaged staff. The reason for it was simple. The college had not presented with them a purpose or opportunity to be masterful. The extrinsic motivators, salaries and such, were just enough to keep people for a little while and then they would leave. And so the college at the time was experiencing attrition of 35-40% per year and that’s what I meant by inhuman.
“These Real Agility methods presented a change. In fact, people become centric to the purpose!”
When I read the Agile Manifesto I think that it provides us with solutions, and so if our current business problem or business circumstance is that we have disengaged staff who aren’t very productive and aren’t getting along well, then the Agile Manifesto reminds us that perhaps business people and developers can work daily throughout the project together. They can have continual interaction, and then individuals and their interactions become more valuable than the process and the organizational tools that have been put in their way. It reminds us that people should be allowed to work at a sustainable pace. We should build projects around motivated individuals. And that poses questions about how to do those things. What does it mean to be motivated, and how do we build projects around motivated people?
So Agile Manifesto presents us with some challenges, as a mental process, and then when we work through that we understand how it can inform good decisions about how to solve business problems.
“Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future.”
In other words, Agility means being nimble, the ability to adapt to current circumstance, but more than that, Real Agility means that we should approach our work with the intention that we stay light-weight so that when our circumstances change we can adapt without a lot of inertial resistance. So there’s two components there. One is being able to adapt quickly, and being aware of present circumstance but the other is that we don’t want to take on weight and institutional mass, because that’s inertia, the status quo.
