This morning I was speaking with some of our friends at VersionOne at the Mile High Agile Conference. We were discussing Agile practices and the phrase “Kanban-ish” came up.
Being able to point at a common process or approach and say, “Yeah, we do something like that” is really important. If you point at a practice and say, “We do SCRUM” or “We do XP” I would be worried about how agile you really are.
A key to actually being Agile is figuring out what actually works for your team and adjusting your team’s practices to do more of what works, and less of what doesn’t. It’s unlikely that any documented practice fits your team perfectly.
I would argue that a successful Agile adoption is founded on two basic things:
- Understand what your customers (the business and nearby teams) need from your team.
- Meet frequently with your team to discuss how to better deliver on those needs
If you started with Waterfall, and added retrospectives and process change to the mix, you would become more Agile over time. You can skip to something like Scrum or Kanban that seem like a reasonable guess at a process that might work, but don’t stay locked into any “Text-Book” Agile too long. Put the retrospective at the heart of your Agile transformation.
DevOps Corollary: Put really good post-release and post-outage post-mortems at the heart of your adoption of DevOps. This space is new enough that nobody even claims to have all the answers. The driving question needs to be, “How do we deliver better?”
What does it mean to be conscious? Flying across the country earlier this month, I read a recent issue of the Atlantic and in particular an article on anesthesia: “Awakening“. While general anesthesia is designed to make a surgery patient unconscious, we actually know very little about what consciousness actually is. One of the models of consciousness put forward by Giulio Tononi is that a conscious mind is an integrated mind.
When your nose detects a new smell, your motor cortex might quickly respond by inhaling more deeply. The scent is referenced against what you have smelled before. In an instant, you recognize a perfume your grandmother wore, visualize her, and emotionally respond to the memory. A conscious brain pulls all this together and integrates the experience. An unconcious brain receives the signal from the nose but does little with it. Dr. Tononi is working to measure this by stimulating one area of the brain and measuring the ripples across others. The image below, shows brain activity increasing in different areas in a patient recovering from a coma.
Image Credit: The Atlantic*
A conscious mind integrates an experience, drawing on various regions of the brain to form a coherent understanding and respond accordingly.
This model of consciousness can be a useful metaphor when choosing how we want to operate as a company or team. Suppose a few software developers are hanging out, playing pool with support guys after work. When asked, “Any cool support questions today?” a support guy responds, “Naw, just the usual people confused by the login screen.” Our friends in development might be surprised to discover a common usability problem, just as most of you readers were surprised by developers hanging out with the support team. Marketing and sales teams that are getting vague feedback about the software not being user friendly would also be able to contribute to this conversation.
At this moment, in a bar around a pool table, a ‘scent’ picked up by one part of the organization is starting to ripple to another area that can respond in the interest of the company. When the login screen is addressed, the company has acted consciously. Continue reading
In past webinars we’ve talked about Lean startups and what the enterprise can learn from them. We’ve pointed to these guys as examples at the extreme doing crazy things like deploying an app to production 50 times a day.
The standard explanation for lean startups movings towards continuous deployment is that they walked a path of removing wastes. Automated deployments were effective in removing errors and wasted effort. The endeavored to speed features to production because features written but not delivered to the customer is seen as wasteful “inventory”.
This is no doubt at least partly true. But when you read discussions of the practice there’s generally a heavy emphasis on monitoring deployments and rolling them back if Continue reading
In last week’s “DevOps Imperative” webcast, I mentioned that DevOps is more directional than prescriptive. I mentioned that the key directions to follow were to push towards more collaboration and automation to enable your team to deliver more frequently with less risk.
Four of the principals and laws we cite most frequently in white papers and webcasts can help reinforce this direction and provide some needed checks as you begin transforming towards an organization whose path from idea to value (the software development lifecycle or SDLC in stodgy terms) needs to be more DevOps friendly.
What it is: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”
Why you should care: Conway’s law points out that when we design some solution, and we put three teams on the project, the solution will likely have three sub-systems and the Continue reading
That ALMOST looks like nail. Doesn't it? Image courtesy of Justin Baeder
In 1966 Abraham Maslow said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” Maslow gave us all too much credit. When we have a hammer and know how great it is, we not only treat everything as a nail, we actually perceive everything to be a nail. One develops a blindness to “non-nail” problems and creative problem solving takes a back seat to picking up that hammer and smashing the problem.
For those of us in the tool-making business, this blindness can be our greatest weakness. We know our tools extremely well, and know how to bend them to purposes outside their sweet-spot. When Continue reading
This week I presented at the Mile High Agile conference. Along with Urbancode, the usual suspects were there as sponsors. The agile project management vendors Rally and VersionOne had the biggest displays, and a pile of consultants and trainers filled most of the sponsor tables. But, then there was a traditional operations vendor who has little app-dev focus.
As I chatted with some attendees, the general response to Ops vendor and an Agile show seemed to be confusion. It made a world of sense to me. While developers, and managers were the most common types at the conference a number of operations folks attended. They were feeling pressure from Agile development teams to release more often, and while still very suspicious of Agile, wanted to pick up insight into what these teams were doing, and see if any of the Lean or DevOps techniques might apply to their own problems. Vendors who are traditionally in the operations space, will be targetting these people as well as app-dev teams looking to better work with their operations groups. They’ll do that under a DevOps banner.
I fully expect to see Ops vendors sponsoring more frequently at Agile events. Within a couple years, the attendees will also probably expect them, and understand their role in helping operations get nimble enough to support Agile.
Update: I presented at the show and the slides from my session “From XP and CI to DevOps: The evolution of automation and agile” are now posted on slideshare.