When I was an ADC (Application Development Consultant) with Microsoft Premier Support for Developers, I wrote the following draft of a proposal merging the development aspects and support/operations aspects of my job.
This was around 2004. Notice the quote from Steve Balmer “almost every company is becoming a software company”. This was seven years before Andreessen’s famous post “Why Software is Eating the World” in The Wall Street Journal.
As I showed it around to my colleagues, at the time it was not well understood as most of the ADCs considered themselves as account managers for development support questions, and more recently this trend has crystalized by the position having been renamed as ADM (Application Development Manager) to align with TAM (Technical Account Manager), whose focus is on support for infrastructure such as Exchange, Active Directory and Windows.
I was on the right track as today DevOps has taken hold, and it has become mandatory to view development as inseparable from deployment and operations.
I want to thank a Microsoft Principal ADM who reviewed this post and mentioned the following:
“Nice article but already dated since we are in fy17 and too many changes to list :-) roles, titles, and org are all different under Satya”.
I agree, Satya is doing a great job in rejuvenating Microsoft. When reading this post you should look away from role names/definitions and other specifics, and focus on the core message of built-in supportability that current cloud software development requires. Enjoy.
(Note: a couple of charts came from Steve McConnell and other friends at Construx, and I have left its copyright notice. The same applies to ITIL.)
Proposal for ADC account strategy on dedicated accounts in the Enterprise space
This paper is an exploration of possible ways to better leverage ADCs in dedicated accounts. Some of its conclusions are also applicable to smaller contracts as well.
Based on some informal surveys, it is fair to say that most ADCs today spend most of their time providing “General Consulting Services” or in laymen terms, ad-hoc and unstructured break-fix advice to developers.
“Ad-hoc general consulting” is mostly characterized by its lack impact on the organization as whole. It is usually a “one-time-only” request, relegated to a small subset of the organization.
While this might the best option in a couple of situations, in most cases those requests are not really aligned with the business drivers for Enterprise IT organizations. Most of them would fall under the “staff augmentation” and “training needed” category if in depth case analysis was to be done.
Historically, Premier has recommended that in bigger accounts, ADCs should ideally spend their time (60% or more) in mostly Proactive activities. We propose that less than that is an anomaly, and a plan should be developed to bring the account to this state.
Implementation will clearly vary by ADC skills and account background. In the beginning of the contract, ADCs might have to go down to the "down to the metal" until all outstanding reactive issues are worked out. But later, the ADC should also start increase his value to the organization.
Driving business value to the customer
In his address of 1/30/2004, Steve Ballmer refers to Platform Competition and makes two key references that have the potential of driving the ADC work in the Enterprise on what really matters:
[…]While Longhorn client and server will be absolutely critical to our future, we must also continue to innovate around and re-energize the existing Windows platform today, and ensure that we’re addressing key customer concerns about security, reliability, manageability and cost of deployment and ownership.
[…] Software provides insight and oversight, defines intellectual property and business processes, and increasingly is the way we interact with other people, groups and organizations. The result is that almost every company is becoming a software company. While people may view Dell as a manufacturer, or Wal-Mart as a retailer, it is their software that makes their successful models work. Persuading these “new ISVs” to build on our platform is as important as winning the traditional ISV.”
So the challenge is, ADCs have to be more strategic as well, as they are today in the ISV space.
In typical Enterprise space, an ADC will be part of a CIO’s IT organization at some level. IT is a cost center, and so focus is on optimizing budgetary constraints, while in the ISV space the ADC is working for the COO at some level, software development deliverables are the company’s product, and so it is a profit center (see Strategic Alignment: Leveraging Information Technology for Transforming Organisations, J.C. Henderson, N. Venkatraman 1993).
So until companies in the Enterprise space realize they need to see themselves as “new ISVs”, the best way to provide value is to align with current IT shops business objectives. And those are usually related to Steve’s first paragraph mentioned above. Ultimately, security, reliability, manageability and cost of deployment are all summarized in Total Cost of Ownership (TCO), and a CIO’s job is to minimize it. That’s what is driving IT shops today to try and run their operations with less and less people, and more and more consolidated servers. Dell’s stated objective is to bring IT costs down to less than 0.8% of their revenue.
So anything that an ADC proactively does to improve in those areas, will be seen as supporting an Enterprise IT’s business objectives.
The need for a common theme
Opposed to ad-hoc work is, of course, work done with a predefined objective or what I would call “theme”. Taking into account the previous observations, and the fact that ADCs are primarily part of a Support organization, I would suggest that in the Enterprise world ADCs could use, as a business vision for their work, the following statement: "to decrease development support costs across the custom application lifecycle".
Two classic slides from Steve McConnell will better illustrate the point for proactive work and business value:
The slide is self explanatory. It may cost from 50 to 200 times more to fix an issue that was introduced in earlier project phases.
Now look at the next slide below. Where would ADCs provide more value: on the red zone or on the green zone in the next slide? It is pretty obvious when seen graphically.
Why would a customer be willing to pay premium for dedicated resources that only work on the red part of the curve, when they can have savings at least 50 times bigger when working on the green one?
ADCs as process improvement catalysts
Given that we clearly established above the need for Proactive work from a business perspective, how do we proceed to implement it?
The best way to decrease support costs is taking a proactive stance and act on the real root cause of issues. In ITIL terms, ADCs should proactively work with IT on the problems, not just ad-hoc incidents. This implies the need to understand the profile of an account, and classify their issues beyond the shallow root cause that we have been normally delivering our customers.
Despite the pioneering work by Lymbourner and others, the current case analysis deliverables suffer from basic misconceptions that blur the line between problems and incidents, cause and effect, and therefore do not allow us to provide convincing feedback to the customer so they can focus on the green curve (problems) as opposed to incidents (red curve).
When first interacting with the account, we should do a quick assessment of the most important reactive issues, take care of them, and then with this solid base, proceed to work on creating value through proactive work on the underlying problems. The ADC becomes then a process improvement catalyst.
Which Problems should an ADC concentrate on
Given that we should proactively concentrate on problem resolution in our time with the customer, which ones are those?
In the Enterprise space, problems that will eventually cause incidents on Production are related to application “aspects” that are frequently overlooked.
Whereas MCS consultants also work with customer business requirements, ADCs will primarily work with requirements that have direct impact on application supportability. I call them “aspects” because in fact they cross-cut all types of applications at all levels, be it requirements, architecture, design, coding, testing and implementation, as opposed to business requirements which are specific to the solution domain.
These problems are deficiencies on usually called “non-functional requirements”. You will recognize some of them from Steve Ballmer’s email, but here is a more complete list:
The ability of an application to be present and ready for use.
The ability of an application to be administered.
The measure of an application's operation under load.
The ability of an application to perform in a predictable manner.
The ability of an application to match increasing demand with an increase in resources.
The ability of an application to protect its resources.
Issues with any of those aspects hit the IT budget bottom-line, because they all impact TOC (Total Cost of Ownership). Work done to improve any of those aspects is therefore indicative of ADC alignment with IT business objectives.
ADC offering as aligned with support improvement
One area that has typically been neglected by ADCs in general in the “ad-hoc wandering round”, is the connection of IT business objectives mentioned before with ITSM (IT Service Management). From the documentation:
“IT Service Management is concerned with delivering and supporting IT services that are appropriate to the business requirements of the organization. ITIL provides a comprehensive, consistent and coherent set of best practices for IT Service Management processes, promoting a quality approach to achieving business effectiveness and efficiency in the use of information systems.”
Usually ITSM is associated with Service Delivery and Service Support, and such subjects are deemed as part of “TAM-land”. However, ITSM is much more than that, and one key topic unknown to most ADCs is Application Management:
Application Management is the superset, which describes the overall handling, or management, of the application as it goes through its entire lifecycle. This lifecycle encompasses both the application development phases and Service Management activities noted below. By bringing these two disciplines together, the goals of IT Service Management will be accomplished more easily through the delivery of applications that are more operable and manageable.
(From ITIL Service Management 2.0)
Application Management “combines the phases of application development and Service Management" In Microsoft parlance, Application Management translates to a combined MSF/MOF lifecycle:
This topic is the subject of an entire book, so I although there is a lot more to explore, I would like to emphasize that as part of Dynamic Systems Initiative (DSI), Microsoft has a clear path to satisfying most requirements from the ITIL Application Management topic "Aligning Application Development and Service Management". One such objective (I consider a niche for ADCs since it presupposes a long term persistent relationship with the customer) is:
Application designers who can design for functionality specifically aimed at Service Management; in fact, they could design applications that are ‘management ready’.
By supporting this objective with their customers, the ADC is in fact solving support problems from the architecture perspective, and aligned with support improvement.
Question from a budding Scrum Master, who is
transitioning from a background as a traditional project manager:
“In order to promote team bonding and self-organization,
from now on I am going to try something new with the team. In the sprint planning
meeting, instead of me breaking down the tasks for user stories between each
team member, I am going to just identify tasks and hours needed and leave it at
that, and then I will ask each team member to “pick” tasks from the sprint
backlog on their own, and later, as soon as they complete a previously picked
The behavior I want to encourage is the
member will see their list of pending tasks as dynamic, depending what is
remaining for the team and not just for the individual as assigned in the
beginning of the sprint
members can pick new tasks to work on, they will need to self-organize, that is,
communicate and coordinate with the other team members instead of just focusing
on their own part of the effort.
Has anyone tried something like this
before? Essentially this is a 'pull' system instead of 'push' system where the
instead of someone assigning tasks to team member, the team member decides
which tasks they want to work on.”
My answer, in my experience as a Professional Scrum Master, and Professional Scrum Trainer was the following:
“Your recommendation is definitely a best practice for Scrum Masters. In organizations still transitioning to Agile in many cases work is distributed exactly as described, by "breaking down the tasks for user stories between each team member" (that is, "assigning" work).
Notice that the word "assign" is neither in the Agile Manifesto nor the Scrum guide. Both use the generic and not well understood term "self-organizing":
- "The best architectures, requirements, and designs emerge from self-organizing teams." (Agile Manifesto)
And from the Scrum Guide:
- "Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team."
- "Development Teams are structured and empowered by the organization to organize and manage their own work."
- "Development Teams have the following characteristics:
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality"
- "The Scrum Master serves the Development Team in several ways, including:
Coaching the Development Team in self-organization and cross-functionality"
- "By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment."
So what does it mean to be self-organizing? Besides its general concept, in the context of software development it means, among others things, bottom up estimation and planning at least at the sprint/team level, Development Team peer pressure to balance workload (the Development Team knows who is not pulling their weight), overall proactiveness from the Development Team to go after what needs to be done to achieve the sprint objective instead of waiting for task assignments. By the way notice that this ideal estimation and planning process is different from your approach, which is to "identify tasks and hours needed " yourself. The team should do it.
In a section of his book "Agile Project Management with Scrum", Ken Schwaber summarized how we tend to succumb to expecting others to make decisions that we should be making ourselves:
"Being managed by someone else is totally ingrained in our life and work experience. Parents, teachers, and bosses who teach us to self-manage instead of striving to fulfill their expectations are rare. Why should we expect that when we tell a Team that it is responsible for managing itself, it will know what we are talking about? “Self-management” is just a phrase to them; it isn’t yet something real. A Team requires concrete experience with Scrum before it can truly understand how to manage itself and how to take the responsibility and authority for planning and conducting its own activities. Not only must the ScrumMaster help the Team to acquire this experience, but the Scrum Master must also do so while overcoming his or her own tendencies to manage the Team. Both the ScrumMaster and the Team have to learn anew how to approach the issue of management."
In essence the following principle from the Agile Manifesto best summarizes what is needed:
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
During a meeting in the early days of the Agile Manifesto, several renowned Agile experts met (www.cs.umd.edu/~mvz/pub/agile.pdf) and came out with the following definition for an Agile process:
"Agile Methods are:
- Self-organizing (The team has the autonomy to organize itself to best complete the work items.)
- Emergent (Technology and requirements are “allowed” to emerge through the product development cycle.)
All Agile methods follow the four values and 12 principles of the Agile Manifesto."
Doing the first two is easier. The bottom two are the last mile of Agile adoption, and require from the Scrum Master a constant team education effort.”