The Scrum Myths videos have been popular and I’m very happy with people’s comments about the videos. I’m going to be making an even more extensive new series for publication in just a few weeks.
Unbeknownst to me, the videographer, my brother Alexei Berteig, created a bloopers video from some of the many, many, many, MANY mistakes I made while making the videos. I hope you will watch it…. but I strongly recommend taking a look at one or two of the “good” videos first. Try these:
Very few people are paid to chat or write email: executive assistants and lawyers mostly. Everybody else is paid to do other work like write code, build things, solve problems, or transact with customers. Think about what you’re actually paid to do, then do that and only that.
If the Slack channel side-bar represents your definition of “collaboration”, stop! If you need to communicate with others while doing your work, do it face-to-face whenever possible or by phone & video. To be clear: Slack channels may be good for announcements but quickly digress as water-cooler drivel and those chatbots are sorry excuses for actual event logging. Perhaps it’s reassuring to be reminded that there’s nothing in Slack (or Yammer/HipChat/Asana/Jira/Trello) more important than the work you’re actually paid to perform.
If your “Sent Items” folder is a CYA repository, stop! If it’s necessary in your organization to CYA then document your activity in a personal journal and stop involving other people in your CYA habit.
If your Inbox is your to-do list, stop! Use sticky-notes, a hipster PDA, or a calendar.
Travis Birch and I are going next week to the SAFe Program Consultant (SPC) training with Dean Leffingwell. For Berteig Consulting, this will be an opportunity to expand our knowledge and to, perhaps, offer some new services including training and consulting. Of course, there have been many articles written about SAFe from a Scrum perspective, but I’m hoping to write an article about it from an enterprise Agility perspective. I have been involved as a coach and consultant in a number of such transformations, and I’m interested to see what I can learn from SAFe and perhaps how it can help to improve our Real Agility Program. I currently consider SAFe to be a “pragmatic” approach to enterprise Agility vs. a “transformative” approach. This perspective is based on some light reading and 3rd party reports about SAFe… clearly not a good enough base of knowledge! I’m looking forward to bridging that gap!
Of course, I don’t mean to say that we should never be sceptical. Rather, sometimes we just have acknowledge reality: there is no magic to make a red line with a green marker. The role of the expert is to clarify reality to others through their knowledge and experience.
When I am doing CSM and CSPO training, I often am faced with people who want to know how to make high-performance teams with distributed team members. They are often looking for some sort of magical solution. This is an example of not being willing to face the reality that distance makes communication slower, less effective, and less likely to happen at all.
I’m sure all of you have interesting experiences of being the expert in something and your audience pushing you to find the magical solution… share your stories in the comments please!
Earlier today at the Inspirational Expo in London Ontario, I met two young, enthusiastic people: Brette Hamilton and John Preston. Brette and John told me that they had grown frustrated with working in traditional media and had started 100 Monkeys as a way to bring a positive focus to the world… to share stories that would help rather than hinder, discourage, or cause grief. Their tag line is “A positive media site”… I hope you take the time to visit them! Here is a photo from the event:
Thanks to Brette and John to a great attempt at building a professional career on something positive! I wish them well, and I hope you all visit them often, and help them out in whatever way you can! (Sharing the link is probably the easiest! Twitter, Facebook, LinkedIn or your own blog!)
Here’s a fun article on PMI.org. By omission, it gives some very bad advice about estimation. What is it missing? Asking the people who are going to do the work!!! Any estimation method or approach that fails to ask the actual human beings who are going to do the work about the effort required is going to be badly wrong. (Of course, even asking the people who are going to do the work is no guarantee of good estimates.)
The starting point of the linked article is a study that showed 90% of projects having cost overruns. To me, this just shows the futility of predicting the future, not anything about how we can (and should?) make better estimates.
For the past several weeks, I have been helping a small charity solve a dilemma. Because the charity is well-recognized for their good work, they regularly attract volunteers who want to help. Unfortunately, the two overworked staff members are too busy to recruit, train, and manage them. My approach has been to use OpenAgile, an open source system for delivering value to stakeholders, to implement a few simple techniques to help them.
There are several aspects of OpenAgile that fit very well for managing volunteers:
1. Self-Organizing Behavior
This means people “volunteer” for tasks instead of doing them based on a tightly defined role or having someone tell them what to do. This frees the staff from having to assign work. Instead, they identify priorities and rely on the volunteer’s creativity and personal motivation to do the task in their own way.
2. Shared Responsibility for the Workload
When there is more than one volunteer, they work in a team and share the responsibility for the workload. The team of volunteers discuss the priorities of the organization, and decide among themselves what tasks need to be completed. Then, they create and commit to a 1-2 week short-term plan that will deliver those results. Finally, they come back after the 1-2 week period and reflect on what they accomplished. This pattern of action, reflection, learning, and planning is one of the Foundations of OpenAgile.
3. Visible Tasks
This means that all people doing the work should be able to see what tasks needs to get done, what is in progress, and what tasks are done. One technique that co-located teams often use is simply posting tasks on a wall using sticky notes. (Check out my OpenAgile Task Wall Prezi) Another cool idea is Card Meeting which works on the same principle, but it can be useful for distributed teams.
4. Learning Manifesto
The emphasis on learning is perhaps the most important aspect of OpenAgile that aligns with the needs of volunteer management. The Learning Manifesto states that “Learning is the key that unlocks human capacity.” Volunteers are drawn to an organization because of its vision but can get pushed away when they feel they’re underutilized or not able to contribute in a meaningful way. By making it explicit that the volunteer is primarily accountable for learning, the organization creates a safe space for experimentation and innovation.
Imagine your father is in surgery for a routine tonsillectomy. Something goes wrong with the anesthesia and his heart goes nuts. The defibrillator is brought out, the paddles applied to your father’s chest and the surgeon yells “CLEAR!”. He triggers the defibrillator, but nothing happens, just a small clicking noise. He quickly checks the machine, and everything looks okay. He tries again. “CLEAR!” There’s a small buzzing noise and your father’s body trembles slightly. The surgeon puts the paddles down, and, getting frantic, yells at the nurses to find another defib machine, “NOW!!!”. Thirty agonizing seconds pass. One of the nurses rushes into O.R. with a cart with another defibrillator machine on it. It gets set up. Another fifteen seconds pass. It charges and the surgeon applies it again. “CLEAR!” There’s a huge shock and your father is killed instantly. It takes a few more minutes for him to be officially pronounced dead.
Is this how projects are run in your organization?
If this had been a description of a real event, you would be furious. You would demand that the defibrillators work better – one hundred percent of the time would be about right! You would sue the hospital for buying shoddy defibrillators. You would sue the company that made them. You would sue the surgeon.
Let’s stop running projects this way. Agile is a reliable defibrillator for your organization’s heart.
I subscribe to the European Baha’i Business Forum newsletter which often posts interesting articles and interviews about the relationships between business, corporate responsibility and social and economic development. In his interview, Satareh discusses the need for closer collaboration between corporations and NGOs and how opening up this kind of discourse will contribute to advancing the corporate social responsibility (CSR) movement.
I found this intriguing in light of the BCI team’s current project of developing the OpenAgile™ Learning System™ and the corporate learning institute.
Five Ways that Team Members Build Trust. The five things Esther mentions are all good and actually seem fairly comprehensive as categories. I often think about trust and it’s relationship to Truthfulness. I see truthfulness as comprising:
Integrity – acting on your principles with wisdom and without compromise.
Honesty – telling the truth as you understand it to other people.
Self-Awareness – knowing your capabilities and limits (being honest with yourself).
What else is required for Truthfulness and Trust-building?
Two very interesting videos. The first, a presentation by Rod Jeffries, goes through a treatment of “Lateral Violence”. The second is three role-play scenarios to demonstrate the concepts. Both of these videos are in the context of nursing in hospitals… however, it takes little imagination to see how they apply in other environments. I would actually assert that the problems described in these videos are endemic to most organizations.
Scrum and other agile methods all have some mechanisms for dealing with this sort of challenge, but they can start failing quickly if the sponsors of the agile effort do not overcome the habitual and cultural challengs.
Most business persons and businesses understand the concept of strategic alliances. The reason to form alliances are many and varied and include such reasons like; monetary, distribution, market access, shared technology and others. My reason for joining Berteig Consulting is a little unusual. First reason is that I am an international consultant, trainer and coach. My international work requires 100-150 days of travel outside North America every year. I have been doing this for 10 years and it does not hold the same appeal it did in the beginning of the travel. Don’t misunderstand me, I still like the travel but I pay a price physically. So joining a reputable and successful Canadian company was appealing to me.
My second reason for the alliance is that I am very impressed with the knowledge, skills, abilities and professionalism that exists in the Berteig Consulting team. Their values were consistent with mine. During the summer of 2008, Mishkin Berteig (the co-founder of the Berteig Consulting) and I began to investigate how we could work together.
Needless to say we hit it off. There is mutual respect. So I made the move to become a CSM and begin to train, coach and consult within his company. Mishkin and I have already decided to co-write a book about Agile. I have currently written 5 books which are published in 10 languages, one of which is a best seller. Mishkin and I hope to publish in late 2009. I will continue my international work to some degree, but my strategic relationship with Berteig Consuting will become more important in the coming months and years.
I look forward to adding value to Berteig Consulting, the team members and all of our clients. I will do what needs to be done to insure the existing and future customers receive the best advice, coaching and training available in the Agile marketplace. I care about the people at Berteig Consulting and will make sure they receive value from me. There is a quote I respect … People don’t care how much you know until they know how much you care! We at Berteig Consulting care about the quality of our interactions with our customers and the results of our efforts.