As a developer SSH is something I have to think about maybe once every few months when I’m setting up a connection for someone pairing in tmux for example. Cutting and pasting public keys can cost real time when a line feed gets inserted inadvertently or something gets clipped.
So assuming ssh isn’t working and you can’t connect it turns out there’s a pretty helpful debug mode on the client and the server. For the client you simply add the -v mode and get a pretty good idea about what’s going on:ssh -v email@example.com -i ~/.ssh/tmux_ssh
If that isn’t enough then you can just launch another ssh service on another port in debug mode.sudo /usr/sbin/sshd -d -p 4444
Then you can just connect your client to the debugging server with a port specification:ssh -v -p 4444 firstname.lastname@example.org -i ~/.ssh/tmux_ssh
From that you should be able to get enough information to quickly debug the problem.
(My first experience with SSH was way back in 2000 when our 16 year old Unix sysadmin switched all the developers to SSH from raw telnet overnight because he could. All of us were on Windows or Classic Mac OS back then without any default SSH client software, and it cost us at least a day of pain to get everyone back to work.)
Thought Exercise One
Let’s say for the moment that I am the CIO of a mid-sized company. I have a team of 100 or so people building software. Let’s also say that those 100 people are largely dedicated to 10-15 smaller products, there are few dependencies between those products, and we are currently using traditional project management to coordinate the flow of value across the organization.
Let’s also say for the moment that my traditional project management approach isn’t working so well and I seem to have as many Project Managers as I have developers. I hear about this new way of working called agile, send my Project mManagers to a CSM class, and when they come back, I reorganize my people to be dedicated to products.
I give each product a product owner, maybe let some of the project managers or team members play the ScrumMaster role, I start building backlogs, plan in releases and two week cycles, and do all the roles, artifacts, and ceremonies prescribed by Scrum. I’m wildly successful with this new approach and now I am a convert to Agile.
Thought Exercise Two
Let’s say I get bored in my old job because things are going so well, so I decide to get a CIO gig with a larger more established company in the area. As part of my department, I have 500 developers working on a large monolithic legacy COBOL system. I have one core product, several smaller products, and market offerings that are a mix of several different products.
Like in my first gig, my new team has been using traditional project management to build software and it isn’t working. Because I had so much success with agile in my last company, I want to try out agile in the new company. I break all 500 or so of my people up into small dedicated teams, I find Product Owners, and I turn my Project Managers into ScrumMasters.
We are meticulous about doing Scrum the right way. We’ve named people to the roles, we are doing all the ceremonies, we are doing all the artifacts. Even thought is seems we are doing everything right, we aren’t getting the same results we got last time. All the training, coaching, and executive support isn’t making any difference this time around. What changed.
So What Did Change?
It’s tempting to want to blame the people. It’s tempting to want to blame how well they followed the process. It might even be tempting to think that agile doesn’t work everywhere and just go back to the old waterfall way of working with renewed vigor. The reality is that agile worked in the first company by accident. It failed in the second company by accident too.
The processes associated with Scrum are designed to work when you have a small cross-functional teams that can operate independently from all the other small cross-functional teams in the organization. In the first scenario because you had products, with little or no dependencies between them, the environment was a natural fit for agile and it worked.
In the second scenario, you have a situation where the environment was not conducive to agile. You had a monolithic infrastructure, poor architecture, competing business goals, interdependent products, and the teams could not work with any degree of autonomy. Too much coordination was required and it was difficult to make an independent decision.
This is something I see sometimes when we are out talking to executives about agile. You see, most executives at this point are familiar with agile. Some like it and believe it works. Some have seen it fail and are not bought into it’s benefits. Some executives have had success in one company and have failed in others and aren’t sure why it didn’t work the second time.
I call this phenomenon accidental agility. Accidental agility is when the processes of Scrum are native to what you have in place and they work without everyone fully understanding exactly why. We learned Scrum and it was just awesome. The trick is understanding why Scrum works, and what conditions lead to it’s success.
If those conditions are in place, great. If they are not, you have to create them. Following a process outside the context it was designed to operate within is a recipe for disaster.
Photo by Immanual Giel (CC BY-SA 3.0)
400 years ago, Hamlet wrestled with he question “to be or not to be?” He was contemplating his own possible suicide. He was not the first to ponder this. Many have dealt with this question since then. It is a nuanced question. Should someone kill themselves after a particularly crappy product demo? (If so, I would not be writing this.) Is suicide reserved for the terminally ill? In any case, this is not a post about suicide. This post is about the question that keeps rearing its head in the agile community: should agile development be estimated? If so, what should be estimated and how?
I began developing software in the late seventies. As a lead developer and project manager, I was often involved in estimating. I worked for what was called a time sharing company. In those days, human time was cheap and computer time was dear. There were no microcomputers. Small and some medium size companies could not afford their own computers. They went to time sharing companies and service bureaus to buy computer time. At these companies we would program the solutions they needed We sometimes charged for this programming and sometimes not. The money was in charging for the running of these systems month after month. The estimates were guesstimates. Sometimes I guessed, sometimes the salesman guessed and other times management did the guessing. In any case, it was what Fred Brooks would call “gutless estimating” in “The Mythical Man Month.” Of course, the estimates were poor. Nobody cared as long as the software went into production.
During the eighties, there was a change in the economics of software engineering. Programmer productivity become more important. Software development teams had to plan their work and work their plan. Estimating was part of this. This decade saw the development of many estimating tools like function points and COCOMO. By the end of the eighties I was working for CSC. My client was an insurance company that I was helping to develop their own waterfall life cycle methodology. As part of this I helped them develop an estimating methodology. As the nineties began, estimating and programmer productivity became my primary focus at CSC. During that time, no one ever suggested that estimating was not necessary. It was just considered to be part of proper planning.
In retrospect, it is possible that some of these estimates were unnecessary. CSC did some software development on a fixed price basis. It wold seem that these bids were always driven by an estimate. Sometimes, they were and sometimes they were not. We might get some competitive intelligence that told us that EDS was going to bid $12 million for the job. If we decided to attempt to undercut them by $2 million to get the work, function points and COCOMO might have little effect on the decision. Most project were done on a time and material (T&M) basis. On the government side, this same contract vehicle was called cost plus. Whatever the name, the reality of the situation was that a customer would continue to fund development as long as there was confidence that the team was going to produce the desired software in a time frame and at a cost the customer could live with. Some of these projects were successful, others waste millions of dollars before being abandoned.
In 2003, I decided to begin work on a doctorate in computing. I enrolled at Pace University. They had an executive program that led to a Doctor of Professional Studies (DPS) in computing. The faculty of this program had been teaching about and using agile development techniques for several years. They taught their software development courses using agile development methodologies. They broke their classes into teams so that they could learn to use eXtreme Programming techniques and later SCRUM. I wanted to apply the estimating approaches that I had used the decade before to agile software development. The department chairman, Professor Fred Grossman, was enthusiastic about the idea. Professor Joseph Bergin, one of his senior faculty members, was not enthusiastic as all.
Joe’s feeling was that you cannot estimate the time and effort involved in a project early in the life cycle. There was no point in trying. Instead, he suggested that someone should be willing to fund a development project at $250,000. This would allow a team to be assembled and the first few iterations of software development to be performed. He believed that they should be estimating stories with story points. After these first iterations, they would have a delivery rate, or velocity, associated with implementing the stories. Then the rest of the project time and cost could easily be calculated by applying that velocity to the remaining story points in the story backlog. Of course, Joe was still estimating, it was just a delayed estimate.
I had two problems with Joe’s approach. My first was that no one would give him the original $250,000 without a proposal with an estimate attached. A decade later, I am not so sure. I have seen people invest in all kinds of things without a clear idea of the expected payback. Much of the venture capital that is raised seems to be built on a sketchy idea and the presence of some credible individuals in the company being financed. There are other examples. In the seventies and eighties, Red Adair was the man you called if you had an oil well fire. He did not give estimates, he simply billed for the work he did. Members of the medical and legal professions often commence work without any kind of fixed price in place. Embarking on an important software development project without an estimate does not seem as far-fetched to me any longer.
I also believed that the initial iterations of an agile software development project are not representative of later ones. In particular, the velocity of doing them is likely to change. There is usually a learning curve associated with the first iterations. People are just starting to work together as a team. They may be using technical tools and techniques that are new to them. I believed that this made the initial iterations too unstable for reliable estimating. I still believe this.
Meanwhile, I was working as a function point counter and estimator. This decade saw a transition from more traditionally planned projects (TPPs) to more agile development projects. The function point community was not happy about agile development for the most part. Agile development projects did not produce the type of detailed system specifications that we were used to when looking at TPPs.
Fairly detailed documentation is usually needed to do a function point count. The should be a conceptual data model with the attributes specified. The counter needs descriptions of the interfacing files along with fields they contain and a list of the entities from the conceptual data model that they interact with. They need screen and report layouts along with data entities that they interact with. With TPPs, they often did not get all of this and had to attempt to make due with other artifacts that were available. With agile development, this information was seldom documented anywhere except the source code being developed.
People using function points to do early life cycle estimating had the same problem. Early in the life cycle there are no data models or detailed layouts of files, screens or reports. Thus, the function points cannot be counted. They must be estimated. Several approaches to estimating function points have been in use. I developed the Early Lifecycle Functionality Estimating (ELFE) process. ELFE provides an estimate of an an application’s size, in function points, at a point in the software development life cycle before function points can be counted. ELFE is designed use initial user stories to drive this estimate. I also developed a collaborative technique called Elf Poker to develop the initial user stories if necessary. Thus, Elf Poker and ELFE could front end traditional estimating models like COCOMO II and CORADMO to provide estimates of the time and effort necessary to complete the project. In any case, I wrote this up for my doctoral thesis. Both Fred and Joe were on the thesis committee. There were no more questions regarding the value of estimating in general. However, maybe someone should be considering whether estimating agile development projects is always valuable. When it is not, time and money could be saved by skipping it.
Ron Jeffries is one of the authors of the eXtreme Programming methodology. He has taken a real interest in the No Estimate Movement. His interest alone would give the movement credibility. Jeffries claims other proponents. Arlo Belshee is best known for his work on promiscuous pairing. Joshua Kerievsky is the author of “Refactoring to Patterns.” Chet Hendrickson coauthored “eXtreme Programming Installed” with Jeffries. All of these seasoned agile practitioners advocated some version of No Estimates. For all, it seems to involve not estimating user stories. For some, it may be a more pervasive approach to not estimating. In any case, Jeffries singled out Woody Zull and Neil Killick as being the primary voices of the No Estimate Movement.
Woody Zull is known for his work on mob programming and considers himself a No Estimate Pioneer. He became interested in some work being done by Vasco Duarte. Duarte wrote a book called “No Estimates.” The first thing that comes to mind is why do you need a book to tell you not to do something. Why not just stop? If there is someone compulsively estimating jobs, fire them. The book starts by quoting the Standish Group’s Chaos report. In summary it states that human beings are not very good at software development in general. However, we are geniuses at software development compared to our abilities as estimators of software development. Duarte takes about 40 pages to make this point. For people involved in estimating day in and day out, he is preaching to the choir. For people less familiar with estimating, even those involved in software development, it may be eye opening.
There are another 150 or so pages in Duarte’s book. Does this just tell you not to estimate many different ways? No, the answer lies in the book’s subtitle: “how to measure project progress without estimating.” We are all kids sitting in the backseat of the family car on the way to Disneyland. Are we there yet? When will we be there. The answer to the first question is no. The No Estimate kids have to wait until dad has driven a few hours before he can answer the second question. Likewise, the No Estimate agile groups must wait until they have collected their own project data before answering the inevitable question, “when will the release be done?” This is what is explained in the No Estimate book. I had a flashback to Joe Bergin’s comments from a dozen years ago.
Neil Killick is best known for his No Estimates work. His blog, neilkillick.com, shows that he is a No Estimate guy who understands that estimates are here to stay. But as estimators, we must understand that rumblings from the No Estimate community have been going on for a long time and their ideas are also here to stay. We have to identify those cases where no estimate is really needed and not do estimates for them. We have to identify what does not need to be estimated and who should not be involved in the estimating process at all. For example, it may make sense to allow software developers to spend their time developing systems and find someone else or some other way to produce estimates that might be necessary. The objective must be to deliver what our customers need. Sometimes this will include a complete estimate with cost and schedule, sometimes just a rough completion date and other times simply an assurance that work is progressing satisfactorily. We need everyone’s ideas to see that agile processes deliver value every day.
A chapter about Sustainable Pace has been added to my new book Continuous Improvement – Doing whatever helps to become better and thus more valuable:
Agile promotes that teams work in a sustainable pace to deliver value to their customers. When teams are working under too much pressure, technical debt will increase and velocity of teams will go down. Under such circumstances it will be almost impossible to do any improvement. A sustainable pace is an essential condition to enable team to improve continuously.
But here is my take.
I think most people are reasonable.
If there is a better way to do something, they’ll consider it.
Just because they resist, doesn’t mean they are afraid.
It might mean you haven’t made a compelling case.
It might mean that they have legitimate constraints that you haven’t taken into consideration.
It might mean that they don’t value the same things you value.
It might mean their priorities aren’t the same as your priorities.
It might mean you haven’t created enough safety.
Sometimes we show up with a shiny new hammer and want to think that everything is a nail.
We are past the early adopter phase.
We aren’t talking about small startups here.
We are talking about large organizations that have been building software for a long time.
There is technical debt.
There is legacy code.
There is a legacy organization.
We are talking about large scale organizational refactoring.
That can be scary.
How do we make it safe?
2016 has started, my wish for everybody is to make it a great year. So let’s focus on doing real improvement to make it happen!
Several workshops on agile retrospectives and increasing agile value have been planned in 2016.
- January 26: Make Your Agile Retrospectives More Valuable at the Agile Practitioners conference in Tel Aviv, Israel.
- February 16: Getting More out of Agile and Lean with Elabor8 in Melbourne, Australia.
- February 18: Valuable Agile Retrospectives (beginners) with Elabor8 in Melbourne, Australia.
- February 19: Valuable … Continue reading →
As of today, the Scrum Alliance identifies 322,157 people as Certified ScrumMasters (CSM). You can find 66,813 people identified as Certified Scrum Product Owners (CSPO), and a number of people have both certifications. Although the anemic number of Product Owners relative to ScrumMasters raises some questions, the more serious problem is the drop-off in people reaching the next level. Only 3,943 people achieved the level of Certified Scrum Professional.
This is not a small problem. This is an order of magnitude problem! And we need to solve it.
We need more people with three or more years of Scrum experience and demonstrated initiative to continue learning.
We need more people who have learned how to be successful leveraging Scrum to increase organizational value. And we need them to continue their success and to help others achieve success.
We need more Scrum coaches - both enterprise coaches and people striving for the new team coach certification. We need organizational change experts or, at the very least, people who have been through at least one change experience and have learned what works.
And we need more trainers. The 191 trainers and 80 coaches aren’t getting any younger. At the current rate of growth of CSPs, we may have a shortage of certified trainers and coaches within five years.
So, if you agree that the Scrum Alliance does have an important problem to solve, you may be wondering the same thing as me…What’s going on with the hundreds of thousands of people who haven’t reached CSP yet?Could the certification be too hard to achieve?
The answer is subjective. To apply, people must:
- Be a current holder of an active CSM, CSPO or Certified Scrum Developer credential.
- Have at least three years of Agile/Scrum work experience within the past 5 years implementing Scrum in any role.
- Gather and submit 70 Scrum Education Units (SEUs) from the past three years.
- Invest $100 to apply and $150 when approved.
And people get a head start - 16 SEUs from the CSM class, up to 24 from CSD, and/or up to 16 from CSPO - and those certifications could have been earned more than 3 years prior to submitting the application. All other SEUs need to be earned within 3 years of the application.
So, over 300,000 people meet the first requirement. Based on membership statistics, over 150,000 people meet the second requirement, assuming they continued to apply Scrum after their classes in 2012 or earlier.
Perhaps the SEUs present a challenge?
- Up to 45 SEUs may be earned from Scrum events like gatherings, local user groups or other Scrum Alliance events - 1 hour of participation = 1 SEU.
- People can earn an unlimited number of SEUs working with CSTs, REPs and coaches. People can apply their initial training for this category.
- The next category is up to 15 SEUs at events outside the Scrum Alliance - like Agile conferences or other training.
- People can also volunteer to provide non-compensated Scrum services for up to 15 SEUs.
- The next bucket of up to 15 SEUs is independent learning - reading a book, preparing a presentation, watched a training video, writing a blog post or article, almost anything could apply.
- The last category of up to 15 SEUs is other collaborative learning.
My subjective assessment is that gathering 70 SEUs isn’t too hard. So many activities qualify for credit that getting involved and continuing to learn in multiple ways seems very possible for most people.Could the certification lack value?
Objectively, the market perceives relatively low value. A quick (unscientific) Monster.com search yielded 57 jobs for CSP compared to 1,432 for CSM and over 1,000 more for Product Owner. Further, while the number of CSPs continues to grow, the rate is nowhere near CSM or CSPO growth, which leads me to believe potentially qualified members may not perceive a lot of value either.
Subjectively, the value far exceeds the effort. For at least the short term, the CSP designation distinguishes people within the Scrum Alliance as high achievers. In the long run, CSPs will advance to team and enterprise coaching certifications and/or Certified Scrum Trainer. Beyond the extrinsic value, completing the Scrum professional certification provides intrinsic value - achieving the next level of personal mastery.Could the membership lack awareness?
Based on the people I meet in my CSM and CSPO courses, I observe very low awareness about the Scrum Alliance certification path and I make time to discuss what people can do next. In the past year, we collected additional qualitative and quantitative data that also shows relatively low awareness in the community. The upside - people ask a lot of questions about what to do next once they learn about CSP and the more advanced credentials.Now What?
The Scrum Alliance community, particularly the certified trainers and coaches, as well as current CSPs, needs to increase CSP awareness and encourage more people to apply for CSP. We also need to reach out to organizations, particularly human resources, managers and other people who plan hiring and write job descriptions to explain the different credentials and the value of CSP (and the coaching designations).
And we need to offer help to navigate the journey. While the CSP FastPass program exists to provide extensive in-person and online training, one-on-one mentoring, group discussions, SEU tracking and application assistance, we continue to assist CSP candidates outside the program. If every trainer and coach helped one person a month in 2016, we could triple the number of new CSPs compared to 2015 and nearly double the total number of CSPs globally.
When it comes to agile, what’s the least you can do? If you're serious about improving what you deliver but your efforts are frustrated by apathy—or even hostility—when presented with change, how much change should you present? Do you have to change everything?
I’m not putting this out there to encourage laziness or offer an easy way out. “Agile light” shouldn’t be anyone's goal. But with unnerving predictability, I see great companies with awesome people and unbelievable opportunities in front of them fall dishearteningly (or even pathetically) short because they don’t do enough.
Beyond the team-level Scrum/XP and Kanban we all know and love, there are just two practices, that if embraced, deliver on the fundamental promise of using agile methods within larger environments. Scrum alone doesn’t work. The delivery team is such a small component of the overall value chain that while Scrum offers benefits, it really doesn’t shift the needle.The Agile Enterprise
Let’s be clear about what we’re after here. An agile enterprise can pivot, apply its muscle to capitalise on opportunities in the market or dull the blade of market threats. Look at the new products or segments your company has launched and compare them with the products that defined that market. How much of that market, or mindshare, have you already lost?
Before you say, “Yeah, but our customers are loyal/our product has more features/they trust our brand,” think about this. In a world where what started as a site for buying books is now delivering groceries, a search engine company is now an ISP and making cars, and a music label is sending people to space—you have to proceed as if your brand means nothing. The value of your enterprise brand is decreasing, while the liabilities of maintaining an enterprise brand are increasing.The Easiest, Well-trodden, Fatal Path
So, if your goal is to be an agile enterprise and you’re doing water-scrum-fall, stop it. Seriously, cut it out.
Water-scrum-fall is the easiest, least disruptive way of introducing agile into an enterprise. But it should only ever be considered a stepping stone. Move on as fast as you can, even if you’re still not yet great at team agile practices. There are no better motivators for improvement than seeing results and demonstrating value. I struggle to think of a more effective way of undermining success than water-scrum-fall.Get to the Point. You Said Just Two Practices?
Scrum and Kanban aren’t enough: these practices are a given and a gazillion companies can do them well. Being good at team agile isn’t a competitive advantage.
For me, these are the missing components:
- Organizing your work into features
- Planning those features into a two- or three-month timebox
Features are simply small functional deliverables—the units of value our customers are looking for. Features solve customers’ problems: Does this app integrate with Twitter? Is this transaction secure? Does this process send me notifications?
Decouple your features and make them as independent as you can. Get started by estimating how much effort it will take to deliver them and what kind of value you and your customers will get from them. The delivery teams decompose features into stories (this is the link with Scrum/XP/Kanban).
Planning these features into a timebox forces a discussion with stakeholders about which ones are most important. "We have a capacity of 300 points for the next three months. How should we spend it?” Just as you always complete stories in an iteration, you always complete features within the timebox.
Organizing work into features and planning those features into a timebox require very different interactions with stakeholders. Change is always scary, but once stakeholders have confidence in the activities around that change, they’ll realize they’re getting more control, more visibility, confidence to experiment and courage to kill bad investments. Once the product teams have these new tools, they’ll find ways to shorten their own cycles and speed the time it takes to sense and respond to market opportunities. The effect compounds.
I’ve stolen referenced both of these ideas from SAFe®. Working with countless customers, I’ve learned that the vast majority of enterprises need to overcome the next hurdle—quickly—so that their portfolios deliver an order-of-magnitude increase in value to their customers.Is That It?
Of course not. It’s just the start.
The next step may be big room planning, or a more formal adoption of SAFe, or one of the other frameworks like Disciplined Agile Delivery (DaD), Large Scale Scrum (LeSS) or Spotify. The rapidly emerging agile portfolio management practice looks at how we structure around the flow of work and customer value, rather than the more traditional emphasis on utilisation and resource efficiency.
But for now, incorporate these two practices. It’s the least you can do to start achieving tangible results and to create opportunities—without turning everything upside down.David Borgeest
At Agile 2015, we had the opportunity to interview Stacy Lin, senior director of product intelligence at Kelley Blue Book, to find out how their organization is using VersionOne to successfully scale agile project management.
- Kelley Blue Book’s transition proved successful and now VersionOne is implemented across many Cox Automotive business units
- VersionOne offers a single, common platform to manage and prioritize work
- Kelley Blue Book benefited from flexibility to meet the needs of Scrum and Kanban teams
- Cox Automotive now has the opportunity to build an agile community of knowledge within the organization
Kelley Blue Book, the only vehicle valuation and information source trusted and relied upon by both consumers and the automotive industry, started implementing agile in 2005. Initially, the teams began with sticky notes to manage their backlog, stories and tasks. However, as the organization scaled agile in 2007, they realized they needed an online solution that could help them efficiently manage complex projects. Particularly when it came to reporting on the velocity and other metrics, they needed an alternative to the manual effort of entering data into Excel and SharePoint.
After an extensive evaluation of several agile lifecycle management solutions, Kelley Blue Book selected VersionOne because of its usability. They had a pilot for eight weeks with two teams – one on-shore and one off-shore. The teams not only found the solution easy to use, but they also increased productivity. As a result, the management team decided to roll VersionOne out to all of Kelley Blue Book. Since then, VersionOne has scaled with Kelley Blue Book’s agile adoption and now has more than 250 users on the platform. The use of VersionOne has been so successful, that the solution been implemented in many of the business units throughout Cox Automotive, Kelley Blue Book’s parent company.
According to Stacy, “Kelley Blue Book and VersionOne have been very good partners for more than eight years. As agile adoption in the software development industry has grown, VersionOne has continued to add new functionality to support the needs of enterprises that are scaling Agile. VersionOne has been a great support in our Agile journey.”
Now Kelley Blue Book and the other Cox Automotive business units have a common platform and a consistent language to easily manage their Agile initiatives. For example, when it comes to managing its top-rated website (KBB.com), an extremely large and complex website, the product managers and Scrum teams have the platform to efficiently manage their work at all levels. In addition, the Portfolio Kanban Board in VersionOne provides one clear view of where all the epics and portfolio items are in flight, so the leadership can see progress at-a-glance and make sure that teams are aligned with business priorities.
While the organization’s agile transformation started with just Scrum teams, over time there were teams that preferred Kanban. The inherent flexibility with VersionOne allows teams to use different methodologies and still provide an integrated view of all agile initiatives in one platform.
Now that VersionOne has been implemented across Cox Automotive, the organization can share and start to build a community of knowledge. For instance, at the annual Cox Automotive Agile Open, all of the business units get together to talk about their agile practices and learn from each other.
Please visit VersionOne’s YouTube page for more video interviews.
The post Scaling Agile Across the Enterprise: An Interview with Kelley Blue Book appeared first on The Agile Management Blog.
(in Hinduism and Buddhism) a spiritual teacher, especially one who imparts initiation.
synonyms: teacher, tutor, sage, mentor, leader, master, expert, authority, pundit
Go to Twitter and search guru. You’re going to find it applied to anything from Agile to Marketing to Love. To be clear, I wasn’t originally looking for a guru. I just noticed it in someone’s profile and was curious who else thought they were one.
After doing some twitter searches, it’s amazing how many people think they are a guru. Seller? Yes. Teacher? Maybe. Master? I think not.
— Derek Huether (@derekhuether) January 4, 2016
My Twitter post on the topic resulted in an enjoyable conversation with Gitte Klitgaard @NativeWired, who describes herself as an Agile addict, hippie and a pirate, Rob Myers @agilecoach, who describes himself as helping people craft worthwhile products and enjoy their careers, and Mike Kaufman @mkaufman811, who describes himself as a ScrumMaster, Agile Evangelist, and Dad.
The four of us participating in the conversation kept it civil and I believe we all got value from it. After our exchange, I would have to say, I’d be quicker to listen to what they had to say than I ever would any of those claiming to be gurus in our space.
Here is a link to part of the conversation.
The question is,
are self-professed gurus in your domain selling, teaching, or actual masters?
I see guru as one of those terms that is grossly overused. If someone said to me something like “Dude, you’re a guru.” I would be flattered by the comment. I just think I’m driven, obsessive, and passionate about improving things and engaging people. But a guru? No.Thoughts from the community
Do you think the term is overused in the Agile space? Is it overused in other domains? Do you think you’re a guru and grossly underappreciated? I want to know what you think. Add a comment.
I'm going to be at the new Agile Alliance Technical Conference taking place April 7-9 in Raleigh! I'll be presenting a more-detailed version of my "Agile Engineering for the Web" talk:Agile Engineering for the Web
Conference registrations aren't open yet, but I'll update this calendar entry once they are.
One concept had to do with constraints. Anyone that has worked much on projects know that constraints are a big part of it. He talks about three aspects of constraint; feasibility, desirability, and viability.
Feasibility is looking at whether or not something can be done in the near future.
Viability is looking at whether or not it's sustainable from a business model perspective.
Finally, desirability of course is will it be something that people want. In design thinking you want to take into account all three of these aspects as you're working on a project.
As I think back to projects that I have had that have been either successful or not successful, I can see how all of these play into a project's success or failure.
On an actual project, we can test for feasibility by doing something like a spike, a short test to prove out if the idea will work.
Viability may be a bit harder to show on a project. It will take other supporting input such as market research to prove the approach is a sustainable business model. This is probably best done before you go to far in the project.
I think there's a very strong tie between desirability and how agile projects work. It's that whole idea of working closely with your users to truly understand their needs.
I've seen other ties between design thinking and the agile approach. I'll have more to say on the future blog post.
It is a bit crazy to think we are already in 2016 but before we get too far into the new year here is a quick review of what has been happening at Illustrated Agile in 2015.
Thanks to all of the new email subscribers to the blog. It’s been a record year for the number of subscribers this past year and your loyalty and encouragement is appreciated.
For the next couple of weeks, new subscribers to Illustrated Agile will receive a digital copy of my book “Becoming a Catalyst: Scrum Master Edition” for free! I have also included a companion coaching worksheet to download as well so you don’t want to miss out. Just subscribe using the form in the upper right of this page and you will receive the links.
My Favorite Blog Post to Write in 2015
In looking back at the 19 posts from 2015, selecting a favorite means looking back at the easiest to write. Hands down, “What Agile Feels Like” flowed naturally and if memory serves took very little time to write.
“What Agile Feels Like” was the output of conversations with people not very satisfied with the results of their Agile transformation. Many think they have mastered the mechanics of Agile but something still doesn’t feel right. Typically, this happens when the mechanics of Agile clash with a culture still aligned with legacy behaviors and systems. This post explains what I feel and sense from organizations beginning to thrive in an Agile environment and are willing to break free from the past.The 19 Blog Post Written in 2015
Scrum Master Resolutions (2016 Edition)
In my opinion, the role of Scrum Master will need to evolve to stay relevant. Make 2016 the year for you to begin the journey.
5 Questions to Ask Before Hiring or Promoting an Agile Leader
Shaping a positive leadership legacy starts with who you hire and promote. Ask yourself these questions before doing either.
A Scrum Master Job Description
How do you know if the Scrum Master you are looking to hire will be the right fit for your Agile journey. Here is a Scrum Master Job Description template to use for your job postings.
So Different…Yet Very Much the Same
A summary of my time coaching in South Africa and discovering no matter where you are in the world we are dealing with many of the same things.
What Agile Feels Like
If you can’t feel an Agile transformation you can bet it isn’t happening. I’m not saying everyday is a party but the energy being emitted should be palpable.
How to Capture Scrum Master Feedback
Integrating feedback from an Agile team into existing performance management systems can be tricky. Here are a few thoughts on how to capture feedback for your Scrum Masters.
The Anatomy of an Impediment
Most Scrum Masters would say removing impediments are a part of their responsibilities. But what is an impediment anyway?
Is “Protecting the Team” the Right Thing?
A Scrum Master often thinks they need to protect the team from outside distractions. Are they doing more harm than good?
Becoming a Radiating Team
A sure sign a team is not radiating information is when someone requests a status report. Transparency should be a natural part of the DNA of an agile team.
Preparing People for Organizational Change
Change is always a personal journey and everyone’s experience will always be different. With this post, we talk about how we can prepare people for change.
The Deliberate Practice of Being Agile
Can we deliberately and intentionally practice becoming a team? Can we find ways to design the improvement of teams and agility into everyday life? I think we can.
Creating an Environment of Confidence
Many organizations are struggling with a demoralized and weary workforce. Here are a couple of ideas for helping people find, build, gain, and keep confidence.
The Elephant in the Room (A Performance Review Conundrum)
In response to an Ask Anything question from a reader, we dig into how to handle a challenging performance review issue.
An Important But Uncooperative Team Member
It only takes one. Every so often, we bump up against an important team member who creates challenges to creating a healthy team environment. This Ask Anything question provides a few options with how to handle it.
8 Rituals of Amazing Scrum Masters
After coaching and observing many Scrum Masters, here are a few of the rituals of the ones making the biggest impact within their organization.
5 Common Pitfalls for a Product Owner
The Product Owner is a linchpin role for an Agile team. Here are a few thoughts on how to keep them healthy, engaged and productive.
3 Things to Observe in a Sprint Review
Just about everything you need to know about how an Agile team is performing can be witnessed in the Sprint Review session. Here’s what to look for.
2015 New Years Resolutions for Scrum Masters
Slow down and find time for yourself, letting going of control, and investing in experiences. These resolutions for 2015 still apply today.
If you’ve looked at the Scaled Agile Framework® (SAFe®) before and determined it wasn’t adequate for your large-scale development, look again.
The fourth version of the Scaled Agile Framework just hit the streets and includes major enhancements that support large-scale software and systems. For highlights, check out our blog, “10 Things You Need to Know About SAFe 4.0."
Over the past four years, we’ve watched SAFe grow from a nascent framework with its usual skeptics (see this post from a converted one) to a recognized standard. This past year in particular, we’ve seen a surge of interest in SAFe from organizations determined to gain business benefits that team-level agile adoption alone couldn’t provide. Don’t get me wrong, good agile teams—those that don’t fall into common traps—are absolutely necessary; they’re just not sufficient in enterprises that are trying to survive amidst fierce competition.
SAFe 4.0 takes a quantum leap to address the complex challenges of developing software, systems and even systems of systems. In our experiences working with large-scale customers, previous SAFe releases really helped kick off scaling agile initiatives. But once you got past your first two value streams—adequately referred to as kidneys in SAFe—you were on your own to extend the framework. In our Portfolio Agility write-ups last year, we documented the need to go beyond the kidneys by taking a demand-and-supply view of large systems.
Thankfully, 4.0 got rid of the kidney limitation. It added extra brain, including more value at the Portfolio level as well as a brand new and optional Value Stream level for large-scale development.
At the Portfolio level, the addition of explicit practices for managing CapEx and OpEx matches the growing need to include financial concerns in agile transformations. As software enables business strategies, software expenses become a material concern to accounting. But because the Generally Accepted Accounting Practices are still worded for waterfall development, over-expensing agile software happens often. Finance professionals partnering with agile development leaders need new mental models to adapt their accounting practices for agile development—something we provide through our Agile Accounting and Capitalization consulting service.
We validated the new Value Stream level concepts in our large customer engagements. Decoupling business value streams from development value streams is essential to match demand and supply without clubbing the two too prematurely. While working closely with Elekta (see our customer spotlight video and this SAFe case study), we saw this decoupling foster incredible conversations between business and IT.
The strong focus on Kanban systems, including added support for Kanban teams, aligns with what we see as the achilles heel in the software industry—taking on too much work and working on batches that are way too large, ultimately bringing the project highway to a traffic standstill. Kanban boards help you visualize your WiP (the highway) so you can stop starting and start finishing new work. Thank you, Eric Willeke, CA Transformation Consultant extraordinaire for your contribution to the SAFe framework on this topic.
Our fleet of SAFe Program Consultants is anxious to help you use the new 4.0 concepts and share how we’ve seen them work in real-world, large-enterprise settings. These new concepts require an even bigger thinking cap than before, and one of our best SAFe assets is the wide range of experience among our coaches. By selecting CA as your SAFe partner, you don’t just get guidance from one coach; you get the collective expertise of more than 50 SAFe Program Consultants who have actually implemented these concepts in large-scale, distributed environments. How cool is that when you can learn from others’ experiences to boost your success rates?
We’ve bottled up our years of experience in scaling agile into a unique and repeatable approach called Ready > Sync > Go. It combines training, product implementation and Big Room Planning expert facilitation to help you get results from your Program Increment (PI) planning in less than three months.Platform Support for SAFe 4.0
Now let’s look at how CA Agile Central (formerly Rally) features support the new 4.0 concepts.Portfolio Level
One of the most impactful changes in 4.0 is a Portfolio-level refocus on investments and how financial resources are allocated against different strategic goals—further improving the ability to centralize strategy and business value, while decentralizing detailed planning and execution. Now, organizations can effectively form and structure Agile Release Trains (ARTs) at the Value Stream level, while aligning strategy and large efforts across the enterprise. Removing ARTs at the Portfolio level (they’re now at the Value Stream and Program levels) matches the need to clearly articulate business value at the Portfolio level before determining how best to deliver it.
Lean Budgeting: Evolving from project funding to value-stream funding is hard, especially when your company is not fully agile. CA PPM customers who are managing agile and waterfall projects can start practicing Lean budgeting via the CA PPM integration with CA Agile Central. In CA PPM, create an Organizational Breakdown Structure to model ARTs as value stream resource pools. Once Epics are approved for implementation, the integration automatically creates Epics in CA Agile Central for ARTs to focus on the approved Epics.
Thanks to our work with large customers who extended the 3.0 framework to track solution value between Epics and Features, CA Agile Central already supports value stream elements.
Capabilities to track high-level solution behaviors: These collections of Features below an Epic are tracked in the portfolio hierarchy between the Epic level and the Feature level. CA Agile Central uniquely scales by maintaining the data integrity between Epics, Capabilities and Features, so you don’t have to ensure data is tracked adequately.
Value Stream Kanban to track flow of Capabilities: The Portfolio Kanban set for the Capability portfolio item provides specific Kanban states, exit policies and WiP limits that are specific to the Value Stream.
Program execution is the heart—and the legs—of a SAFe implementation. If you can’t deliver on your strategy, it doesn’t matter how good your strategy is. And if you can’t execute, you can’t innovate either. Building a predictable delivery engine is at the crux of scaling agile, so portfolio decisions are based on empirical evidence of delivery. CA Agile Central has strong platform support for PI ceremonies. Releases track the PI timeboxes to plan on cadence, while Milestones track the deployment cadence to deploy anytime.CA Agile Central provides unique capabilities to support all three phases of PI planning
Before PI Planning: Minimize waste at the PI event.
- Capacity Planning: Respect predictability capacity margins. Ensuring product managers focus on elaborating only the features that will fit in a PI is a typical challenge. Our capacity planning functionality acts as a reality check before the PI Planning event, and we’ve extended it to support planning one feature across multiple teams, which helps deliver value to customers, faster.
During PI Planning: Optimize the return on investment for the PI event
- Team Planning: Align stories to their feature context. The Team Planning page, currently in limited beta and available soon in open beta, empowers teams to plan stories that support the PI Features. This is where scaling agile differs from Scrum and where team-level agile tools that only support Scrum fall short in connecting team stories to larger portfolio business goals.
After PI Planning: Track the PI plan during execution.
- Release Tracking displays team plans in the context of program features and surfaces dependencies and risks. Use Release Tracking to assisst with the PI confidence vote and during your steering meetings, to show real-time progress and to spark discussions around priorities, risks and dependencies.
It’s great to see Team Kanban finally recognized as a first-class citizen in the framework. We’ve seen teams dealing with interruptions welcome the Kanban way to track their work, and teams enjoying Scrum find benefits in supplementing Scrum views with Kanban views to shorten lead time and improve value flow.
Team Kanban with classes of services: The Kanban Board app supports the new Team Kanban concept and has swimlanes designed to increase visibility into what matters most to the team.
Communities of Practice (CoP) with inter-team communication: Collaborating across distributed sites and time zones is a way of life in enterprise settings. The Flowdock capability is built for 24x7 communication so teams can get fast answers from their CoP.
CA Agile Central also supports the following concepts that transcend all SAFe levels:
Requirement Model Traceability Support (Epic>Capability>Feature>Story). The Portfolio Hierarchy provides trustworthy rollup reporting by reliably maintaining traceability between the new Capability artifact, its parent Epic and its children Features—without any concerns about data integrity (as each requirement type is its own portfolio item type).
Enablers to track exploration, infrastructure and architecture work. Track Enablers as Stories or Portfolio Items with a boolean custom field to differentiate the Epic/Capability/Feature/Story from enablers. Then, visualize the Enablers work and the non-Enablers (Epic/Capability, Feature/Story) with a Kanban to maintain a good balance of architectural runway vs. customer value delivery.
Scaling agile is no small feat, but you can ease the challenge by selecting a partner that provides you with unmatched expertise from actual SAFe implementations and a scalable platform that supports all the SAFe core values—program execution, alignment, transparency and built-in quality. To learn more about our support for SAFe 4.0, visit our SAFe toolkit page and register here for our “Get Ready for SAFe 4.0” webinar, co-presented by Dean Leffingwell, on February 9 at 12 p.m. MST.
A few posts ago I mentioned that I roughed in some 20 plus articles I intend to write over the next few weeks. By the time this one goes out, I think you’ll have seen two or three of them. It was interesting to take a step back and see where my head has been these past few weeks.
There was a clear pattern emerging.
In any movement… and yes, I see agile as a movement… you have lot’s of different constituencies.
You’ve got consultants with something to sell. You have evangelists interested in advocating their particular point of view. You have thought leaders interested in advancing the state of the art. Each bring their own set of biases and their own unique perspective to the conversation.
(For the record, I fall into all three of these categories in some form or fashion)
As folks consume our collective wisdom on all things agile, many of them are not as well informed, or as well read, or even have the time and inclination to dissect, understand, package, or repackage these ideas to make them work in their organizations.
Many… not ALL of course… are operating from a partial playbook.
I believe the principles behind agile are inarguable. I believe that many of the patterns and practices that make agile work are inarguable. I think agile fails when we implement these principles and patterns and practices in an inappropriate context.
Everything written by anyone that has ever written anything on agile is from their own context, their own point of view, and based on their own experiences. To assert otherwise is nonsense. When we package our agile experience up into a thing, all that context gets lost.
That said, the market demands a simple, pre-packaged solution. It demands a two-day training course. It demands an easy to read one-pager describing the process. The market wants agile to be simple and understandable. Something that can be purchased off the shelf.
The reality is that it’s nuanced. It’s unique to the organization. There are no simple answers.
As I started looking through my notes from the past few weeks, and in all honesty… my last few years of writing… my last few years of company building… and my last few years of consulting… it’s all about discovering language that helps people understand without pretending its easy.
Themes that emerged were around safety, leading change, dealing with resistance, failure modes, and success patterns. My brain is absolutely centered around the fundamental base patterns that work and how to break down barriers to their application in real companies.
My brain is focused on how to package all this stuff up into something that is marketable and meaningful, not necessarily by describing the end state, but by describing how to package all this up into a safe and effective model of iterative and incremental change management.
In other words, what’s the process of transformation. What do the intermediate states look like and how do we get there? There is so much noise in the system… so many competing points of view… how do we cut through the bullshit and get to something that works for us.
Shifting gears, a little…
This morning I woke up to series of blog posts and tweets lamenting the fall of agile. How agile doesn’t work. How we are post agile and that agile has failed. One of my favorite bloggers was debunking the latest agile myth in an attempt to bring some sanity to the conversation.
To some extent, I think we are experiencing a pendulum swing in the industry. On one extreme, we have the waterfall boogeyman, that for the most part has been roundly marginalized in the industry. Still there, but not very popular right now.
On the other extreme, we have a total anarchist view of agile based exclusively on empowering people to decide, telling managers to back off and leave folks alone, but failing to give the people spending the money any assurance they’ll get any value for their dollar spent.
The answer isn’t extreme control over every detail. The answer also isn’t total lack of control over time, cost, and scope constraints that give our investors some reasonable assurance they’ll get something of value for their money. For most companies, the answer’s in the middle.
If you decide to pay attention as I get all this stuff typed out, what you are going to see is an exploration of the thinking tools, the organizational patterns, the failure modes, and processes I think are necessary to really lead change in large enterprises.
I’m not talking about the squishy, feelings related stuff, around change… but the hard… how do you actually do it kind of change. How do you form teams… specifically? How do you create a governance model… specifically? How do you measure stuff… specifically?
I believe there is a bunch of good that can be had by adopting a team-based iterative and incremental approach, out of helping people get clarity around what to build, and helping people understanding what to measure. I also think it’s okay to tell people how to get started.
If that’s too prescriptive to be agile… I’m good with that.