The Rangers have delivered a sample data tool around March. Now they have put it to work and created a sample data set based on SAFe. It makes it a lot easier to demo features and processes when applying the framework as well as being a learning tool on how to structure your SAFe project.
I will be studying these two Ranger contributions on how to also make it work with Scaled Professional Scrum. Stay tuned.
Date: July 6, 2016, 11:00 EST (15:00 UTC)
Join Ken Schwaber and Jeff Sutherland, the creators of Scrum and the Scrum Guide in this rare opportunity to hear them together talk about Scrum. The focus on their presentation will be on the upcoming changes to the Scrum Guide (http://www.scrumguides.org/),why they have made these changes, what the changes mean for Scrum and Scrum practitioners around the globe.
For more information:
https://www.scrum.org/Resources/Scrum-and-Agile-Webcasts?utm_source=Mautic&utm_medium=email&utm_campaign=ScrumGuide
To attend:
https://attendee.gotowebinar.com/register/5307820190467155203
Martin Hinshelwood (Visual Studio ALM MVP and Ranger) will be presenting on how to use SPS enlightens us on scaling professional Scrum with Visual Studio Team Services.
This is quite relevant and a long waited talk as Microsoft has presented on how to do SAFe with VSTS a while ago.
As Martin mentions, “Tools don’t solve problems, but they can help reduce the friction of Scaling Professional Scrum. The only way to successfully scale across multiple teams, maybe in multiple countries, is to create robust automation and orchestration for minimising the risks, and time, of manual tasks. Visual Studio Team Services allows you to create a robust, platform agnostic, support structure that can start where you are, and grow as your needs mature.”
You can reserve your spot with GoToMeeting by going to this page: https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/1017/Scaling-Professional-Scrum-with-Visual-Studio-Team-Services--ScrumPulse-Episode-13. I recommend tuning in early as it tends to get crowded and it is a limited number of slots.
July 3rd Update: the page I linked to has been updated with a recording of the webcast. You can also watch it directly in YouTube.
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
Summary
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.
Current status
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:
| Availability | The ability of an application to be present and ready for use. |
| Manageability (Operability) | The ability of an application to be administered. |
| Performance | The measure of an application's operation under load. |
| Reliability | The ability of an application to perform in a predictable manner. |
| Scalability | The ability of an application to match increasing demand with an increase in resources. |
| Securability | 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:
| ITSM Phase | MSF/MOF Phase |
| Requirements | Envisioning |
| Design | Planning |
| Build | Developing/Stabilizing |
| Deploy | Deploying/Changing |
| Operate | Operating/Supporting |
| Optimize | Optimizing |
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.
In incremental service update to Update 1 has been made available. A “servicing” update is actually a bunch of hotfixes packaged together over a full Update. In the old days it would be called a Hotfix pack to a Service Pack. Interesting how nomenclature changes over time.
As for its contents, it fixes the nagging issue with Update 1 in that Visual Studio would unexpectedly crash while debugging. See this page for more details. Please keep them coming. This particular issue was painful to live with, even if for just a few weeks.
The new version 14.0.2 has been released and can be downloaded at the Microsoft Download Center.
Brian Harry self-effacingly called it “small update”. However for the teams at many companies who have been using TFVC but want to gradually move to Git, it has a huge update: you can now use both in the same team project.
This allows you to get to work without losing your context: you just incrementally move relevant pieces of your code from one repo to another. Previously you had to change context every time you were working on big code bases that lived partially in one place or another. I am now experimenting with it for builds to see if it allows the same ease of transition.
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
task.
The behavior I want to encourage is the
following:
1.
Each team
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
2.
Before team
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:
- Iterative
- Incremental
- 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.”
Do not forget: Azurecon is on the 29th of September. The sessions I want to watch are in one way or another related to DevOps:
- Azure for developers
Gain a thorough understanding of the components of Azure and how you can take advantage of them as a developer.
Speaker: Scott Hanselman
This is a Scott Hanselman's session(!), it is always entertaining and informative, even if you think you already know everything he is talking about he will surprise you with a new twist :-)
Claude joined Microsoft with Incycle's Release Management tool purchase, and now its technology is being integrated into VSO and Azure. A must see if you are a DevOps practitioner.
This is pretty much the complement of what Claude will be talking about, and both delve into the "last mile" of software development. Again, a must see if you are a DevOps practitioner, with the added benefit of watching Donovan Brown who is now a DevOps program manager at Microsoft.
Outside of DevOps I will be watching this one out of sheer pleasure and my interest on AI applications:
- Applying Azure Machine Learning to software development
Azure Machine Learning has proven to be effective in a variety of application domains, including speech recognition, object recognition, and image retrieval. In each of these domains, Machine-Learning based programs must adapt to changing conditions, handle large data sets, often with irregularities, and come up with algorithms with little or incomplete knowledge. Sounds similar to software development? Turns out that Machine Learning is being applied to the field of software development, including reverse-engineering legacy code, software fault-detection, and requirements analysis. In this session, you’ll look at various examples of how Machine Learning is being applied to software engineering problems.
Speaker: Vishwas Lele
I will add some of my notes and comments to this post after the event. Enjoy!
I took the 26th of September, a Saturday, to attend MeasureUp, a free conference provided by ClearMeasure, a provider of custom Cloud (especially Azure) development services in Austin.
I have known Jeffrey Palermo for a while ever since we had a chance of briefly working together at Dell. Later he successfully applied his deep knowledge, discipline, and personal charisma (Jeffrey’s parties are famous) into entrepreneurship to create his own consulting company which became ClearMeasure.
The conference was an interesting combination of technical and business sessions, all highly relevant and cutting edge. While on site I I happened to focus mostly on the business related talks except for a couple sessions, but will later come back and watch the other technical sessions as well, as they represent leading trends going on in application development.
Here is a quick list of the sessions I attended, Hopefully my brief notes will help decide to go ahead and watch when they are available at UserGroupTV. I will be updating this post as recordings are released.
9:00 Enabling Continuous Delivery – Justin Mason
Justin went over the foundational concepts of CD using Humble and Farley's book as a reference, while adding his own extensive practical experience when providing practical examples of how the ideas might be applied. This experience has been extracted from working with hundreds of companies, which made his recommendations even more authoritative.
10:00 Success as a Remote Worker: Love your Job, Have a Life. – James Chambers
James works remotely for ClearMeasure out of a 35,000 person town, but he is on top of all things 
MVC6 so he pretty much interacts with the world through the window provided by working remotely from his home. That takes a lot of discipline and know-how, and this great talk explains some of the best practices he has achieved. The talk was so good that it made me look forward to his next one on MVC6.
11:00 Behold the Power of the PPO! – Kevin Hurwitz
Kevin started by spelling out why the emperor has no clothes, and explained that the biggest lie he had been hearing in the last ten years is that having a Product Owner in your project will solve all of your disconnects between what is asked and what is delivered.
After making the case for a PPO or a Proxy Product Owner, he explained why this person has to be:
- 50% Developer
- 50% Analyst
- 100% Owner
It bodes well with Scrum.org thinking itself when it recommends to developers that you should know the domain as well as the product owner themselves in order to make a valuable contribution. Kevin ideas reminded of the concept of Chief Programmers and Chief Architect in FDD, but the difference is that he achieved his definition of PPO in the course of working with 160 plus customers and asking what worked and what did not when interfacing with the PO and/or end user.
Again, another seasoned contributor so I could clearly see he was speaking out from a different kind of experience, forged in the reality of solving thousands of problems in the line of duty of customer satisfaction.
12:00 The Leading Measures of Velocity – Allen Hurst
Watch it at http://usergroup.tv/videos/the-leading-measures-of-velocity
Allen’s take on the concept of team Velocity expanded it into beyond the one commonly known to Agile, taking into account other factors that affect teams, including, for instance, morale and management styles.
To the end this talk was more about metrics in general, and how not to overdue their usage while gathering enough to be able to consistently plan your releases. As with some of the other talks, I will have to watch it again as Allen provided many interesting references for follow up.
2:00 Reshaping the Company- Continuous Deployment and Culture Change
– Gabriel Schenker
Watch it at http://usergroup.tv/videos/reshaping-the-company-continuous-deployment-and-culture-change
In Gabriel's presentation I could see my own experience when going from totally undisciplined production release habits in my earlier jobs, to the almost precision-clockwork sophistication of some of the teams I work with.
The take away was that without changing the culture, implementing CD will be only as successful as the cargo-cult teams ability to mimic improvements, but eventually if these practices are not internalized and become second nature, they will die under their own weight.
4:00 The DevOps Silver Bullet – Peter Siri
Watch it at http://usergroup.tv/videos/the-devops-silver-bullet
In this talk Peter took the commonly assumed concept that there are no “silver bullets” in software development, and moved it upside down by showing his own idea of what that silver bullet would be. I will not spoil the surprise by giving away what his analogy is, but as with any good vampire movie, it kept my attention to the end. 
5:00 MVC6 – What You Need to Know When Moving to Next – James Chambers
Watch it at http://usergroup.tv/videos/mvc6-what-you-need-to-know-when-moving-to-next
James went over the latest and greatest on what is coming in MVC6 – and then I realized how much I need to catch up on my MVC knowledge. It was one of the richest presentations on an upcoming technology I have heard for a while. This one will I will definitely have to watch again, as soon as Shawn Weisfeld, our Microsoft Technical Evangelist for the Cloud, publishes it in his http://usergroup.tv/ website. Thank you Shawn for your contribution to this event.
