It's hard to believe that it's been six years since my last blog post. The time seems right to emphasize the power of team Charter and Tenets.
I have a great deal of "why?" that I may add another post.
I offer this as an example for others, to set expectations for those that want to join our team, and also learn from your experiences!
This covers a 200 person team within a 900 person team distributed around the world. We built this with representation across the organization to gain the best and most diverse perspective.
Data Protection Engineering Charter and Tenets
We protect and allow instant recovery of a third of an Exabyte of critical business data for millions of Partners’ customers worldwide.
To deliver our products’ promise, we operate distributed applications and storage systems in the cloud and physical data centers. Our products also facilitate Partners’ use of third-party data protection systems, giving them choice. We build, operate, and relentlessly improve our services under rigorous international compliance standards. This extends our data protection stewardship to rigorous data privacy and security standards.
Supporting The ConnectWise Way, our charter demands our builders’ actions demonstrate that we Act as Owners with Agency as follows:
Prioritize People
Everything we do is an opportunity for our team members’ growth. We deliberately align team members with challenging work to help them grow. Everyone learns, everyone teaches.
We solve problems for our Partners, their Customers, and our Stakeholders. We use evidence of impact to celebrate individual and team achievement.
Deliver Results Predictably
We focus and align our most precious asset (our team) and our most precious resource (time) to deliver value quickly. We provide estimates to help our stakeholders make the best business decisions.
We maintain predictability by prioritizing the remediation of risk and dependencies early. We embrace change but reject randomization. We collaborate with our stakeholders using data, align expectations, and quickly pivot when needed.
Stay Curious
We turn over rocks and are unafraid of what might crawl out from underneath. We ask questions and invite others to learn together.
Bias For Action
Experimentation prevents prolonged deliberation. We make incremental, reversible decisions that enable us to quickly learn, iterate, and move forward.
See Something, Say Something
We share by default, calling out opportunities, obstacles, and concerns. We encourage our team to ask for help and escalate or involve other experts when blocked.
Build the Right Thing, the Right Way
We partner with Product to prioritize the problems we solve and identify opportunities for innovation.
In every solution, context counts. We embrace pragmatism while rejecting mediocrity.
Maximize the Whole
While many paths led us here, we are all one ConnectWise. Focus is good, silos are not.
We are responsible for making Asio our singular future platform and improving it as we integrate. Our Partners benefit through simplicity, and Engineering innovates faster with a common platform.
We warmly welcome your feedback and suggestions for improvement.
After joining AWS a few years ago, I found myself building and operating the largest distributed and scaled systems of my professional career. The following news sources that were previously interesting and useful became crucial for my day-to-day life.
InfoQ - Direct content primarily sourced from hand's on practitioners and reviewed by editors. Check out the Architecture & Design section.
DZone - Articles (70k+), Refcardz (200+), Guides (30+), and Zones (14 categories, nearly all relating to distributed systems at some level). While the Zones cut across many areas, I find Cloud, Big Data, and Database especially useful.
High Scalability - Weekly digest in the world of distributed/scalable systems plus some independent and paid content.
Thoughtworks Technology Radar (Platforms) - Thoughtworks has some great minds in the area of distributed software development, and their overall Technology Radar is updated semi-annually with their opinion of where certain areas in technology are moving. Bonus points - build a technology radar for your team!
All Things Distributed(AWS CTO Werner Vogels' Blog) - Recently a great deal of AWS region launches, but occasional and historical distributed/scalable content.
The Next Platform (partnered with UK-based The Register) - Enterprise vendor specific news source - "Offers in-depth coverage of high-end computing at large enterprises, supercomputing centers, hyperscale data centers, and public clouds."
These resources allow me to take others' learnings to enhance my mindset and think and act at 10x in terms of performance, scale, volume, variety, velocity, failures, etc. However, one doesn't need to be working at AWS to require this level of currency. Market expectations now demand that we build and operate (or at least think in the case of prototyping/early development) at this scale across every solution to deliver value to customers and stakeholders.
My offer to present this content to individuals and companies has been well-received and I had a chance to do that as well a few times and am continuing to share what I've learned originally as well as the ongoing discussions I've had in the community. Double cool! Note, this offer is still open!
Here's the latest version of the presentation from SlideShare:
I'm always looking for more feedback, so please feel free to reach out to me for engaging discussions in bridging the gaps that frequently exist between various stakeholders in a product development organization. It's my passion to help us all work #bettertogether!
Ten years ago, I made my first visit to Asia on a work trip to visit my new team in Hyderabad, India. It deserves a separate blog post as it helped me form many opinions on how to have distributed teams work through a bunch of experiences that didn't. Although I've had the chance to work with folks from this area of the world in the mean time, I haven't been back since.
I'll blend right in!
Before the novelty washes away and I become a "local" I wanted to put together a list of what really knocked my socks off on the changes I immediately noticed. I won't go into what hasn't changed (yet)--I'm still the only white guy that I've seen in a week, and the Muslim/Hindu mix (27% / 70%) still produces exotic awe in me to the point that my favorite time pass here has been staring slack jawed through the open air as we drive across town in an auto-rickshaw.
No Immigration Insanity
It's midnight sometime in June of 2005. I've been traveling for over thirty hours and am in Asia for the first time in my life. I voluntarily leave my business class cocoon of comfort and we are marched off the highly efficient and ordered German Lufthansa flight into an area that can only be described as a marketplace of free thought and expression when it comes to immigration bureaucracy.
Through bleary eyes and ears canals that are still full of whatever packs them at 30,000 feet, I witness a visual and aural cacophony of stamping, yelling, and officials (I hope those are officials) with guns forming and reforming lines in a room the temperature and size of a warehouse janitor's closet. Somehow, I made it to the front of the line and people kept cutting in front of me, with every mother's son and daughter yelling at me from behind in an exotic mixture of Hindi and English to "go, just go...ahhhh..don't let him do that..you stay there..stop! move back! move forward! acha acha ACHA! don't go. You have to push forward, don't let them get away with that!"
I finally took the plunge and wedged myself in the fray by the source of the loudest stamping soundand forgot my typical American politeness. It worked! I was at the desk. Mr. Stampy looked at me not once, but kept grunting something indecipherable...it was probably multiple somethings, but it sure sounded the same. I just kept saying "I'm sorry..pardon me? I don't understand" Every response was stamping, which I took as a good thing. When he stopped grunting, I got pushed forward by someone and no one was pointing a gun at me. I walked forward. I had arrived.
In 2015, it's now just like any other immigration desk, and honestly...it's disappointing.
Gone are the Undiplomatic* Ambassadors
We Americans (at least the U.S. variety) have cars hard-wired into our DNA to the point where my son popped out already negotiating what kind of lemon I'd be selling to him when he turns 16. Suffice it to say, I'm always on the lookout for every make and model of car and how they're different than back home.
Walking out of the airport in 2005, it seemed like I was falling back in time into what I envisioned was present-day
Cuba. Every single car not only looked the same, but appeared to have been built in the mid 1950s. The airport was lined with so many of these Ambassadors to and of India to the point that I thought there might be a presidential cavalcade (maybe, just maybe celebrating my arrival).
When I walked out of the new MUCH more modern airport in 2015, I didn't see a single one. They've been replaced with Tatas, Mahindras, Hondas, Suzukis, and many more. It makes it seem a lot less exotic here now.
*I've been referring to these cars as Diplomats since 2005 as well. Oops.
Traffic Lights That Work
I have been raving that NO ONE pays attention to the "stop lights" here in Hyderabad for the past ten years. When I describe the people going against the lights, and many times against traffic in the oncoming lanes, most Indians nod their heads in understanding. But now, my story must change as people really stop at the lights now! I'm guessing that this is due to the fact that most intersections have well-masked officers and some have cameras watching. I'm guessing that the latter don't really work, but the former does.
Perhaps, there's a catchy and highly effecitve advertising campaign like... "D.A.R.E. to stop on red!" or "Better to stop on red than dead."
Here's a recent drive proving we stopped!
Smart Phones Used Unsmartly
This phone went to India with me in 05!
It's not that mobile phones didn't exist when I was here last, heck I was rocking my Blackberry and
emailing and calendaring like a champ! I honestly don't remember locals having them although they probably used them as, you know, phones. I'm sure that this comes as no surprise to absolutely no one that EVERYONE has a smart phone here now. However the thing that really surprised me was HOW they were used.
Here are things that I have observed, but was too much slack in the jaw to take a picture:
Scooter drivers texting and talking while driving
All three riders including the driver of a motorcycle talking or texting (or buying delicious takeaway byrani online) while said 2-wheeler is in rapid transit
A driver and rider on a motor cycle passing the phone between each other, talking to someone while manuvering in highly congested (think 3 cars and 10 motorcycles wide) and weaving traffic
Of course, this perspective is somewhat tainted by living in an area where people put on such airs as banning use of phones while driving and making mandatory the use of child safety seats and adult safety seat belts. #NannyState
Call To Prayer
I'm certain that this one has been going on for a long time, and I just didn't notice it due to the fact that I was staying in the hermetically-sealed location where they hold up all the white people--western luxury hotels and hi-tech offices. As I'm staying with my wife's family this time, I can hear, smell, and see so many more rich and amazing things. One that I heard almost immediately after arriving to their flat my first day here was the Muslim call to prayer around 5:30 AM.
This city has a plethora of mosques and multiple calls to prayer can be heard five times a day. Being outside of the rhetoric going on back home, it's awesome to see Hindus, Muslims, Christians, and so many more, living their lives in an incredibly open, inclusive, and participatory democracy under the Indian constitution.
The goals of creating a roadmap start out well enough--let's give our customers and stakeholders a picture of the future and get them excited about what we're going to deliver in the future. However, the implementation generally fails to delight. They are developed in a silo, are considered by many to be a long-term contracted commitment, and are incomplete. They generally don't give visibility to the exciting and enabling technology and operations/devops changes that are necessary to achieve much of the innovation and major organizational goals. Beyond basic technical debt, these are large changes that must be made in concert between the business (product/customers) and the technology (development, devops, ops, security, etc.) teams and there is opportunity for awesome alignment!
At Socialware I was responsible for serving all of these groups and developed a passion for solving this problem as a whole. This presentation will cover what I learned and give participants real-world examples they can take away.
I just submitted the this to the Keep Austin Agile 2016 Conference. It's tough to get selected as this is a world-class event with a small acceptance rate. However, I'm really looking forward to sharing it if given the opportunity!
Here's the title:
Radical Roadmapping - Creating Synchronized Agile Product and Technology Roadmaps
Here's the abstract:
This presentation will discuss why a company would create and maintain three major artifacts (innovation roadmap, infrastructure/platform roadmap, and operations/DevOps roadmap) as well as the process to do so. Further it will cover how to synchronize them in order to move away from making OR decisions to making AND decisions that will please all stakeholders. It will also discuss key cultural changes that must be present in order to achieve maximum benefit from this approach and challenges experienced along the way to making this a reality at Socialware, a SaaS product company. Finally, this will include real world examples of the evolution of these roadmaps over 18 months that participants can take away and use as guidelines for doing so.
This concept is RADICAL as it is innovative in both its novel approach and ability to drive enormously positive organizational agility.
Of course, in Matt's usual energetic* style, there will be tangents, humorous self-deprecating references of learning (aka failure), and time for participants to describe how this would "never work" in their organization coupled with Matt's re-framing to help them understand how it just might.
*Best feedback comment ever received in his Keep Austin Agile 2015 presentation on Continuous Capacity Planning: "Man, this guy has been drinking way too much coffee for a 4:00 PM presentation!"
Next Steps
Now to create the content based on the real world examples and learning with the team at Socialware--I'll continue meeting with folks in the community, sharing what I have so far and refining it as I go. If you're interested in this concept, please let me know--I'd love to share my ideas!
I'm really proud to have helped push this through to the final stages and receive this critical patent that captures and protects our ability to serve our amazing customers in a way that no one else can.
"This patent really represents the core of our technology, business and purpose," said Matt Roberts, Socialware vice president of product development. "While the language of patents is complex, we make it our mission to assure that social media use and compliance are easy for every financial advisor and firm. The technology behind this patent makes that possible, which is why it's so valuable."
I was fortunate to be selected to present at this year's Keep Austin Agile on May 8, 2015.
Many product development teams struggle through “painful” planning meetings. No one seems to enjoy them but they are deemed necessary for various reasons that all start off with good intentions and critical needs. They typically do not harness the power of being responsive to change and following YAGNI (You Ain't Gonna Need It) and delaying decision until the last responsible moment concepts that are core to true agility (i.e. more waste than the Austin Community Landfill).
In this talk, Matt will provide an approach that he’s used for years to strike the delicate balance of building a product and development roadmap that can be used for long-term planning, short-term planning, and being extremely responsive to change. It’s also respectful of the Agile Manifesto Principles and Values. This approach should make planning an easier, if not fun, for everyone from Developers to Product Managers to Executives. It will include a simulation of sorts, that walks through a short- and long-term roadmap that responds to change as unexpected (pulled from REAL LIFE!) things happen.
Here's a direct link to the presentation. I'd certainly enjoy any feedback in the comments section below.
A "gift" from the team after my latest quality crusade
I had the opportunity to present this information at two Agile Austin QA SIG meetings in September and October 2014. It was a great opportunity to share some of what I've learned since joining Socialware. It's helping me to change the culture for the benefit of our customers and is a key part of "The Socialware Way". Before too long, I expect nearly everyone to say, "Quality is sexy!"
Background
While greenfield development efforts always have the promise of "doing it right" from the ground up, they can quickly devolve into the "legacy" systems that are essentially unsafe to modify as doing so will almost guarantee problems for users that the development team cannot anticipate. Further, many of today's applications exist in a complex and fragile ecosystem of APIs and other dependencies that are beyond the control of a team, division, or an entire organization. A culture of continuous learning is key in combating these challenges to create safe and valuable software for the customers and development teams that build and maintain them.
At Socialware, we have started the process of reviewing all production critical issues in an open and visible manner by using a Quality Circle approach as a team. We call this the Critical Defect Review Process. This is especially important due to the fact that our products exist on top of the constantly changing APIs of LinkedIn, Facebook, and Twitter--the world's largest social media companies. As our company has the largest Social Media deployments by Financial Services firms in the world, who have little, if any, tolerance for problems due to their scale and regulatory requirements, the focus on quality is paramount.
The Goal
The goal of the Critical Defect Review Process is to understand the root cause of why any high-priority defect exists in production and take specific remediation actions to ensure that this issue and others do not occur again. We also establish ownership of any actions going forward. Finally, we keep a recorded log of these issues, which will be reviewed periodically. Note, that the goal is NOT a "witch hunt" in terms of assigning blame. If we are not open to deep understanding, we will never be able to solve the problem. The ultimate goal of this process is to deprecate the process when we have zero critical defects in production, however this occurs.
Implementation
We continue to monitor this process and continuously inspect and adapt it, but currently, this is the basic framework of our Critical Defect Review Process.
Periodicty
This review occurs every three weeks (the same cadence as our sprints) with all resolved production defects marked as either a "Priority 1" or "Priority 2." The reason we wait until they are fixed is that the highest priority is to resolve any customer-critical issues, regardless of their genesis. Additionally, reflection generally helps towards the further understanding of the root cause of problems, and the eventual solution.
Participants
We have the following roles participate at these reviews:
Moderator/Scribe (generally a member of the Development Management team)
Product Technical Lead
Primary Engineer involved
Primary QA Engineer involved
QA Lead
Customer Support Lead
All team members are, of course, welcome to attend and listen
Format
The discussion captures the issue in question, any related issues, the primary engineer associated with the issue, the primary QA engineer associated with the issue, the root cause/synopsis, recommended actions moving forward (remediation), and agreed actions. All of this is captured in our wiki. Note, the agreed actions may be an acceptance of a certain risk within our process, although this is not the primary desired objective. This information will be reviewed at a regular basis by Product Development Management, Executive Leadership, and the team, at the very least during the sprint retrospective. Again, there is no blame assigned, which can only work within the larger context of "The Socialware Way" where our team members are respected, trusted, and treated as our most precious assets as opposed to "resources."
Early Results
While we have only been doing this for about two months, we've seen some fairly impressive results. Not only are the issues trending down, we are also able to respond more quickly and have a deeper understanding of why quality problems exist. Of course, we are implementing a number of other changes to our product development system that result in high-quality customer value as a natural outcome of our system rather than something that needs to be forced. So, the attribution of the increased quality is manifold. I will continue to monitor and share results.
Genesis
The genesis of this concept comes from the concept of a Quality Circle, which was introduced by Dr. Ishikawa. It was interpreted into "cross-functional teams" which was a key part of some Total Quality Management systems. Thoughts?
I would love to hear your thoughts on this process, please feel free to direct message, or comment below. Thank you for your time in reading!
My friend and sometimes colleague John Heintz asked me to play the straight man in his first experiment in professional video blogging. John is a powerful advisor to many agile and lean software engineering teams, managers, and executives around the world and he described the collaborative planning concept as something that he's "drawn on a whiteboard over a hundred times."
His idea certainly resonates with me as I have discussed the concept of "sashimi" for software teams where the phases of development on a particular user story are focused less on strict hand-offs between separate teams and more on overlapping phases of development to collaboratively get work to done in priority order. The hand-offs and silos implicit in the waterfall model caused many problems, especially in getting work to done with high quality. In many teams following Scrum, they have still maintained this model, although in shorter, iterative cycles, creating a "Scrumfall" environment. I've asked Scrum teams that I've advised to consider a model where they attempt to reduce work-in-process by having a number of cross-functional team members "swarm" on each user story in priority order, focusing on architecture, design, development, testing, and documentation with overlapping phases. This allows ample opportunity for real-time feedback to affect each of the now "fuzzy phases", cross-team education, and insight into the earlier phases by team members that may be able to build quality in, versus test (or worse, document) it out.
Protip: when you're planning work around a user story, don't try to model dependencies, just assign a number of story points or hours in a bucket, and let the work flow naturally, allowing the work to be the focus as opposed to the plan or the team member allocation. Monitor the work on a daily basis.
Protip: if you're 40% through your sprint (e.g. the fourth day of a ten day sprint), and all or most stories are in progress and nothing is done yet, you're likely in "Scrumfall" and you are likely performing sequential versus collaborative planning.
Without further ado, here's our first experiment together in video blogging around the benefits of a collaborative planning model:
I presented one of my favorite topics at last weekend's Product Camp Austin 11 here in Austin, TX. While the crowd turnout was fairly small, it was still a great session packed with tons of interactivity. I have presented this content to the Agile Austin community a number of times, so I've been able to synthesize all the feedback from a variety of groups (Development, Product Management, Project Management) into the following slide deck. The best way to convey the information is face-to-face, so I'd be happy to share my insights, challenges, and what we've learned if you have the time and inclination.
I also found this great article by Jeff Atwood titled "Today is Goof Off at Work Day" about the broader topic of open time for developers to innovate.
October 16, 2014
I debated removing this page when I left CA Technologies in April, but thought that I would leave it as a tribute to an incredibly special team that we created together. Unfortunately, as the saying approximately goes, "every positive cultural change is one manager change away from failure," and the overall direction was no longer compatible with my personal values and it was time to leave. Perhaps one day I'll write about that experience. However, I'm really excited about the new team we're building at Socialware, which I've been long-overdue to write about! -m@
July 19, 2013
Welcome!
You've probably arrived on this page as someone forwarded you over a position for our team at CA Technologies here in Austin. Yes, we're hiring in a relatively big way, but we do things a little different here. I thought it would be good that you know a little bit about us before you consider joining.
Keeping CA Technologies Weird
It's important to know our heritage: our team is composed of the former NetQoS and Hyperformix development teams. We are part of CA Technologies, and we don't pine for the "good old days", but we are "keeping CA Technologies weird" in the following ways:
Party Bus w/Karaoke for Offsite Toobing Day
We are entrepreneurial and motivated by delivering direct value to our customers by eliminating waste (as identified by the team members) and eschew process that doesn't make sense.
We are a 95%+ co-located team.
We have fun, but not in a pinball machine/video game kinda way. Don't get me wrong, we have that stuff, but the most fun (for us) is solving really challenging problems with a reach nearly unparalleled by other companies in the local market. Winning is also really fun.
People should be and are unique. We don't have a dress code, and people have flexible work styles. We do emphasize being in the same place at the same time for a good amount of the day, but understand why that's important.
We have a sense of humor and treat people as responsible adults. Experience has shown that the benefits of this far outweigh the risks in this approach.
We ask A LOT of questions around why things should be done, especially when someone else is telling us to do them. We've kinda got a reputation....but that reputation is superseded by our ability to deliver valuable software to our customers and make money. Funny how that works out.
We all figure that a culture of fear has pretty much been played out by now. Individual and team empowerment is engaging--we like that.
Our management team "walks the talk" of acting as servant-leaders. We are here to help things "go righter"
Service Day at KIPP Austin
Why you might want to work on this team
In addition to being OK with the above, you:
Love solving very tough problems and truly love to learn.
Focus on quick delivery to get rapid feedback into what our products should be for our customers
Are inspired by how technologies can affect people's lives for the better
Can deal with constant experiments in how our work is done
Work really well with others in tight teams yet still have independent minds
Are OK with doing any job on the team, but realize that it makes sense to focus on your strengths
Have a passion for building products that deliver real value to customers
Are open to the possibility that all this "agile stuff" just might not be management bullshit. You've looked at the Agile Manifesto and the Principles, and that sounds really good to you. You have hopes that someone, somewhere really pays attention to this stuff.
Want a real work/life balance. This is again, not bullshit. I have not asked the teams that I serve to work a night or a weekend for four years running. We practice sustainable pace (and fully know why we do).
Want to develop your "career capital"--we carve out one week a year for everyone to train and build it into our schedules. Yes, there's budget too. No, it doesn't get cancelled, but you'll need to have some level of independent motivation.
Want a certain paycheck and sweet benefits. CA Technologies is a big company, we enjoy more than five weeks of vacation a year. Yes, you heard that right, and that's before holidays.
I know the above sounds a bit too hard to believe, but you can ask any team member.
At a recent "Science Faire" where the team takes two days
every four weeks to work on their innovative projects.
Why you might not want to work on the team
There's nothing wrong with these things at all, but please don't apply if the following resonate with you, as you won't be a good cultural fit for the team:
You just want to do your "own" work, and it doesn't make any difference where or when you do it
You want someone to clearly tell you what to do and how to do it
You are a <fill in the blank> technologist (e.g. Java, C++, C#, RoR, Scala, Fortran, LOGO, Perl, etc.) and really aren't interested in anything else
You believe that agile, at it's core, just another management fad, as is Lean and all the others. Just let me code and don't worry about process.
Automation is of no interest to you
You are upset with the world for some reason, and believe work is a great place to express it
You have to be the smartest person in the room
Seeing our software running on mobile for the first time!
I recently talked with a manager whose team's role is changing from main line product development to Sustaining Engineering (also known as Maintenance). He first wanted to understand how to adapt the agile process for his team, but as we talked, it became apparent that the bigger issue was keeping his team happy and engaged, as they were a bit nervous about what the change meant for them and their careers.
I was interested in exploring this area with him, and thought it would be worthwhile to discuss the concerns he had for his team. I must be transparent and state that I have never served as a manager for a dedicated sustaining engineering team, so many of my thoughts in this area come without direct experience. Perhaps it would be best to explain why this is the case.
Why Have I Never Had a Sustaining Team?
It's not that I've never had the opportunity to have one, I simply rejected the notion and made it part of the responsibilities of the product development team. I firmly believe that the notion of "sustaining engineering" may be indicative of a failure mode*. Separating the responsibility for how code runs in production can lead to another "throw it over the wall" type of mentality that we as an industry are just starting to make headway on between development and QA. More critically, it can totally disconnect crucial feedback to the product development team causing years and years of waste that could otherwise be invested in creating customer value.
Here are some of the arguments I've heard in support of a Sustaining Team:
"If we could free our development team from all those damn critical situations that come up in production, we could finally get some valuable features out the door and make some money."
"We can get cheap resources overseas to handle fixing the defects and focus our expensive resources on the things that customers really want. It just makes good business sense."
"Development is constantly interrupted by fixing low-priority nits and we keep missing our release dates or drop planned functionality. This has to end!"
"Our releases are too long for customers to wait. A sustaining engineering team will prevent our generally late releases from being even more so."
"Are you kidding me? We can't have our developers actually talking to customers, those guys are a bunch of mutants that can barely communicate with each other!" (OK, I haven't heard this explicitly, but it's certainly implied.)
Each one of these points constitutes a failure mode that I won't go into here, but may be good fodder for another blog post. As agile is "the art of the possible," I didn't see this as an opportunity to challenge the notion of the sustaining team, but I thought I'd help with ideas to make the team as effective and engaged as possible.
*Note: one possibility of a non-failure mode could be a distinction between a team that is primarily interrupt-driven, and one that is focused on long-term goals. This point was brought up by my colleague and may be useful to folks in some situations. However, it is critical that the whole is being maximized for the benefit of the customer, company, and the individual software engineers.
Can Sustaining Engineering be Agile?
Sure--why not? If you look at the Agile Manifesto there's nothing in there that that precludes the values and principals that are universal to software engineering and the humans who are engaged in its practice. Process improvement frameworks geared towards software engineering such as Scrum and Kanban, and the modern engineering practices that support them (e.g. XP, TDD, etc.) are certainly as valid for sustaining a product where the work tends to focus on fix packs, platform certifications, and minor feature improvement.
Some might argue the semantics of "agile" vs. "lean" and say that Sustaining Engineering isn't agile and should be run through a Kanban process. I would tend to agree that there can be benefits of running sustaining requests (essentially tickets) through a Kanban system, if for no other reason than the fact that near constant reprioritizations happen when dealing with a mature mission-critical product that is loaded with technical debt. There tends to be a real need to release extremely quickly to production as well and the changes are smaller than large marquee features/epics associated with new product development.
One of the nicest things about Kanban, however, is it tends to visualize the entire value chain, at least when implemented to obtain the greatest customer value in the smallest amount of time. Seeking to "maximize the whole" may lead to some very beneficial activities, which get to the manager's concern about having an engaged team.
"Re-Imagining" Sustaining Engineering through Engagement
Back to our conversation with the newly minted Sustaining Engineering Manager...He was nervous that his team may not be as engaged in their new work assignments and they would no longer be writing new valuable features and functionality. As someone whose success is more than partially defined by the innovative products that the teams he serves delivers, I can definitely understand his concern. It would be mine if I was in his place as well, and I came up with a few ideas. It's important to keep in mind the context of these ideas--this is a team of product developers who are changing roles into sustaining engineers. I'm not sure that they would apply to every Sustaining Engineering team. My basic premise here would be to put yourself "out of a job" by eliminating sustaining requests through the constant improvement of the codebase. What should be left is platform certifications (browser compatibility, operating system, JVM version, .NET version, etc.) that are always changing and can be handled by the same team now that they have the capacity to do new feature development.
Note: This is not a comprehensive list of "best practices" for Sustaining or Support--there are a ton of those. These are just a few ideas about how to help a team of software engineers be fully engaged while they are part of a sustaining group.
Create a target of business-specific technical debt reduction. Identify common root-case problems in the codebase, often a source of Technical Debt to remediate common-occurrence problems. In general, never have the same type of defect show up more than twice (fix it "right" the first or at worst the second time). It is possible to eliminate enough of this debt where having a sustaining team just won't make sense.
Fix the leak first before mopping the floor. Reducing technical debt by a sustaining team will be useless if there is a product development team continuously creating it and making it worse with each new release. A sustaining team can be engaged in evaluating new code that is delivered and acting as an advocate to increase code quality, or at least prevent new code from creating the next wave of customer critical situations.
Develop and employ modern engineering practices to analyze the code base and ensure that regressions are not "developed" along with fixes. Many legacy code bases have weak automated testing, automated unit tests, and coverage mechanisms. Configuration / builds tend to rely on "magic" of people who are long gone, or at least not accessible.
Act as an alpha tester of new releases from the product development team. No one knows better what kind of problems are out in the field and how the best features may flop when put into production more than sustaining teams. Embed yourselves in sprint reviews (demos) and quite possibly act as the owner of final user story acceptance. How's that for engagement?
Funnel innovation - because a sustaining team operates so close to the customer, they are many times the closest ones to know what the customer pain points actually are. Sustaining members can act as powerful contributors to a product advisory board/committee and have the weight of real customer feedback when they speak.
Delight customers by being able to predictably deliver fixes. One powerful technique to do this involves measuring average cycle time for defect fixes though a process such as Kanban. Scrum iterations can also be used effectively here as well. Most customers don't need their fixes "right now," but have been burned so many times by missed expectations. If a schedule can be made transparent to customers and that schedule is constantly made good, customers will start properly assigning severity to issues.
Rotate with the active product development team. This gets really close to my initial idea of just having one team that does both new product development and sustaining work. Think of this as a hybrid model where there is a constant trade of learning between new product developers and developers that couldn't be closer to customers.
Additional Reading
Thanks to John Heintz (@jheintz) for some additional great reading around Sustaining Engineering, some of which may contradict or amplify the ideas I've presented:
What do you think? Do you agree/disagree with these points? What's worked for you as a Sustaining Engineer to have mastery, autonomy, and purpose in your work as a team member?
Image via Creative Commons, Jose Franco's (jose_franco_) Flickr photostream. (source)
Welcome once again to my friend and colleague, Janice Hamrick, with her latest perspective on helping whole development teams attain agility through effective technical writing. Unfortunately, technical writers, who are crucial members of the product development team, are often siloed for the sake of "efficiency." I've been serving my teams for years by insisting that stories are not complete until there is adequate documentation, and it has driven dramatic positive changes from the perspective of people, product, process, and tools. If you like this post, please check out her other two posts (How Agile is Like a Guitar and Tech Info Fits Into Agile Software Development and 3 Ways to Make Documentation as Agile as Development). ~@MulticastMatt
Some development teams choose to separate documentation from the rest of the development work. In fact, the Society for Technical Communication (STC) recently held a seminar entitled, “Doc Sprints: The Ultimate in Collaborative Doc Development,” which included the following description:
“Many technical writers find themselves in agile environments, where time is at a premium and it can be difficult to pry the developers and other subject matter experts away from their day-to-day deadlines.”
The problem with this practice is that it violates almost every principle of Agile and causes problems for all members of a team.
What is a “doc sprint” as opposed to a sprint?
A doc sprint is just that – a sprint containing only documentation tasks. Often, the only member of the sprinting team is the writer, with nonexistent or at best nominal support from the rest of the team. Dev and Doc are like milk and cookies - they should always go together. If you are having separate doc sprints that lag behind development sprints, YOUR TEAM IS NOT AGILE. Documentation is as important to software development as coding and QA - no story is done unless it’s fully coded, tested, and documented.
Why should it be difficult to pry developers away from their deadlines?
If your team is truly Agile, EVERY team member is responsible for every user story. This means that developers are as responsible for providing content and reviews as they are for coding. If a writer is blocked and a doc task can’t be completed, then the story can’t be closed. This provides the means and the motivation for excellent communication and cooperation among all members of the team, and ensures the documentation gets the attention it needs from all concerned. If a team conducts separate doc sprints, dev and QA have already moved on to something else by the time the writer starts and will have to switch context to provide information. Moreover, dev and QA very likely have not budgeted time into their own sprints to work with the writer – after all, their stories apparently can close without documentation. This leaves the writer in the uncomfortable position of “prying” developers away from their “real work” or resorting to begging (or threats). Plus, the likelihood of missing information altogether (because it’s no longer current) or of being shortchanged during review cycles increases astronomically. The doc quality suffers, team relationships suffer, and ultimately product quality suffers.
Why are writers different from any other team member?
The short answer is that they shouldn’t be! However, in many organizations, tech writers report to a different business unit than development teams, a situation that can leave writers feeling like outsiders because they are treated like outsiders. I know writers who are left off mailing lists, who aren’t included in team-building training, and who are sometimes the last to know about feature changes.
For real Agile success, writers must be real team members. It might not be possible or even desirable to change the management hierarchy of your organization, but it is possible for teams to ensure that writers are first-class team members. The first steps include making sure everyone on the team understands this (management support is essential), eliminating doc sprints, ensuring doc tasks are part of the team user stories, and planning for the time needed to provide content, write, and review the doc.
Is there ever a good reason to have a doc sprint?
Probably not. There might be a reason occasionally to have a doc-only user story (for example, if your team decides the product needs a new user guide), but even in that case the team is responsible for content and reviews. No one team member, whether writer or not, ever works in a vacuum. All stories require commitment by the team, and as such should be incorporated into team sprints.
Your thoughts?
Does your team hold separate doc sprints or are your documentation tasks integrated into the development sprints? How does that work for your team and the quality of your product?
About the Author
Janice Hamrick joined CA Technologies in 2010 as the Senior
Technical Information Engineer for the Capacity Management suite of products
(formerly Hyperformix). Before joining
Hyperformix, she spent years writing documentation for backup and recovery
products for a rival company whose three initials shall remain unnamed. It is a
myth that she has worked as a technical writer in the software industry since dinosaurs
roamed the earth, but she does remember when “agile” was something you had to
be to avoid the saber-toothed tigers.
I have just finished reading a book that is, without a doubt, THE most important book on Scrum that has been published since the original. This book is Tobias Mayer's, The People's Scrum. Why should you read this? You should read this because you are likely in a system that must be improved--I deeply believe that all of us are. You will likely not agree with everything, but in order to truly realize the value of Scrum or any agile development framework, there are things that you need to know contained in this book. If you find yourself in agreement with everything contained within, this will be an excellent reference to share with others who may not be so fortunate. Ultimately, you want to better the lives of your team mates and yourself in ways that are founded on experience and love (how's that for a bold and courageous statement?) It's also a nice fast-paced read as these are essentially edited blog posts, none of which are more than five pages. What was my experience?
As I read this book, it reminded me of the first time I read the Agile Manifesto--my head was nodding in accord so many times, I nearly became dizzy.
Based on the foreword, I was convinced that I would find something to disagree with Tobias on and was looking forward to the opportunity to have a great conversation with him and potentially have my mind expanded. But I didn't...his views are so close to my own as what he says could have been written by me (although I couldn't have written them as well). I suppose that comes as no surprise as one of my early strong influences was Kert Peterson as well. We also seem to share strongly-held (as in concrete reinforced with rebar) views on the importance of humanity, decentralization, and co-location in innovative and creative work.
I suppose I didn't learn too many new things in the book, but they were told in a way to convey important meaning to the people who actually do the work and are the main focus for the Scrum framework. Of course executives and managers should also be exposed to these ideas as they are (fortunately or unfortunately) ultimately responsible for maintaining or at least spawning the systems where the workers create value. These are the people that will receive the most benefit of these essays as I share them with the teams I serve and advise others in the community and our industry.
Agile Austin - Here we Come!
I plan on ordering five copies of this immediately and sharing with the Agile Austin community. We will likely conduct a book discussion group on this book in the July time frame and will report back with comments and observations.
A few shout outs.
Thank you Tobias for this important compendium of essays that continue to be sorely needed across our industry to maximize joy and potential of our people, organizations, and technology users. Also, a big shout out to Bernardo Salinas for catching me in the airport in Austin and recommending (insisting?) that I read this book!
