tag:blogger.com,1999:blog-68452155488699601002024-03-05T01:48:59.935-06:00Mike on IT StuffJust Common SenseMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-6845215548869960100.post-41735978729637995242019-05-14T01:14:00.000-05:002019-05-14T01:15:28.866-05:00Shamrock Mapping - A simple tool for improvement<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLTzY5ryHGvmH41vEXxmMk-Yjj4Q1aklAsFdqNJCF_i13cFtbiTzyTocdihhhdoK4s1BPsSjpdqWgAuGBHaeOZ-ajwsPXoBPr0lm2EfuZJTRgyd0ETvAfDoPVVubuzJAx1vmZKxNY88J4/s1600/ShamrockMap.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="806" data-original-width="1240" height="208" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLTzY5ryHGvmH41vEXxmMk-Yjj4Q1aklAsFdqNJCF_i13cFtbiTzyTocdihhhdoK4s1BPsSjpdqWgAuGBHaeOZ-ajwsPXoBPr0lm2EfuZJTRgyd0ETvAfDoPVVubuzJAx1vmZKxNY88J4/s320/ShamrockMap.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
I am a big fan of <a href="https://medium.com/wardleymaps" target="_blank">Wardley Maps</a> and draw simple maps on a white board or napkin during every discussion of strategy.<br />
<br />
<a href="https://twitter.com/swardley" target="_blank">Simon Wardley</a> says they are imperfect as all models are and that's true - they are also the best way I know to facilitate a strategic conversation.<br />
<br />
<a href="https://twitter.com/chrisvmcd" target="_blank">Chris McDermott</a> has created a nice variation - <a href="http://maturitymapping.com/" target="_blank">Maturity Mapping</a> - that combines Wardley Maps and <a href="https://cognitive-edge.com/videos/cynefin-framework-introduction/" target="_blank">Cynefin</a> to help teams understand and address their maturity in different areas.<br />
<br />
I have recently been using yet another variation that I call Shamrock Maps. A Shamrock Map is super simple and can be used for any part of the value chain. I usually draw a regular Wardley map using Visibility and Evolution as the axes and then zero in on the area(s) of strategic interest.<br />
<br />
For those areas, I change the axes to Autonomy and Mastery - autonomy is our ability to move freely without interference from external factors; mastery is our ability to move freely without interference from ourselves.<br />
<br />
I have been starting with a guess about where a particular activity/outcome lives. From there we observe the external WEIGHT. What policies, external dependencies, governance etc. impede us from releasing our work product into the real world and benefitting from feedback?<br />
<br />
Having identified the top of mind factors weighing us down, we move to LIFT. What can we do to overcome or remove weight? Can we negotiate with an external approver to show our compliance as part of the process? Can we remove our dependence on other teams? Do we need to lobby for a policy update? There might be a lot of actions or only a few - this is a good time to think creatively.<br />
<br />
Having discussed the autonomy axis it's time to move to mastery. Again we start with the impediments DRAG. Are we one deep in a critical skill or knowledge of the domain? Is crucial tooling missing? Is the codebase scary and dangerous to work in?<br />
<br />
Finally we consider THRUST to overcome that drag. Would adding characterization tests help? How about spending a small amount of time doing some structural re-factoring to learn about the codebase while making it easier to reason about? Would making or buying some tool help? Could we use pairing or mobbing to overcome specialization?<br />
<br />
One big advantage I've noticed over the last couple of weeks using this is that we end up talking about impediments and ways to overcome them that had not been identified as addressable. When we're in an environment for a long time, the constraints of the environment become normal to us and almost invisible. Firewall changes take 3 weeks - make sure to account for it in the plan. No! Let's figure out how to make that a non-event.<br />
<br />
Anyway, I have found this approach useful and I'm writing this post because people I have shown this to are starting to use it and then tell me they can't find any information about Shamrock Mapping - now maybe they can :-)<br />
<br />
Thanks for reading and hit me on twitter @mikeonitstuff with any feedbackMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-5296479508666144392018-09-15T21:04:00.000-05:002020-05-06T21:43:49.454-05:00Metrics that matter - or might at leastI've been thinking a lot about how to help align management behaviors to support organizational Agility. I think - still trying this in the real world - that our best chance might be to use the existing structures of incentives with some tweaks to the content.<br />
<br />
We have Job descriptions, success factors, and personnel reviews at our disposal. I might think that those things are impediments to becoming our best selves and yet they prove super durable, so I've been working on how to use them to create a more supportive environment.<br />
<br />
I'll spare you my apple seed planted on a table top analogy...<br />
<br />
For this post I want to talk about organization level metrics that might lead to a better environment and appear hard to game via bad behavior.<br />
<br />
1. How many layers of communication are between the user and the team implementing a solution for that user? The ideal number is zero as shown below, each additional communication point reduces the fidelity of the message.<br />
<br />
<img alt="Image result for telephone game" height="150" src="https://www.gwinnettpl.org/wp-content/uploads/2018/03/telephone-game.png" width="400" /><br />
<br />
2. Average number of projects each person in the organization is working on. One is ideal. When we assign people to multiple projects we essentially abdicate our responsibility to prioritize the goals. It's ineffective, inefficient, and unfair to team members.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://multitasking.labinthewild.org/multitasking/images/multitasking-600.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Image result for multitasking" border="0" height="304" src="https://multitasking.labinthewild.org/multitasking/images/multitasking-600.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
3. Number of projects in flight organization wide. Just like teams and individuals, organizations benefit from limiting work in progress. When we focus on a small number of items we can increase the flow rate - projects get done - and maximize return while having less of our budget at risk.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<img alt="Image result for wip" height="300" src="https://image.slidesharecdn.com/path2agility2014-hefley-140522104731-phpapp02/95/why-limit-wip-25-638.jpg?cb=1400755809" width="400" /></div>
<div class="separator" style="clear: both; text-align: left;">
4. Number of production deployments over time. The point of tracking this against management is to encourage smaller more independent releases reducing execution risk and realizing value earlier.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<img alt="Image result for production deployment" height="216" src="https://image-store.slidesharecdn.com/60384d6c-3998-43ca-8637-c638a308e85d-large.jpeg" width="400" /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
5. Equipment delivery lead time. Almost everything we do requires some sort of equipment. It could be a laptop for a developer, a VM in a private cloud, or the ability to drop a container into a cloud service. Whatever it is, wait is waste. We want to encourage reducing that wait time through the most appropriate means available. It might be automation, negotiation with vendors, or moves from owning to renting.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<img alt="Image result for waiting" height="325" src="https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcT3ZiCoXkzpWqPLzFWuNA5-_4RheS2Rx3J9OBKFehHJmF5fsKW9" width="400" /> </div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
6. Percentage of capital budget allocated. In my heart of hearts I am a cash accounting kind of guy AND the finance folks don't care about my heart of hearts so we are stuck with capital budgets. The more money we have tied up in work in progress the more risk we carry. Every week a project goes without a production release accumulates risk; every production release resolves that risk. We might not like what we have but we know what it is and how much we've spent. We want to encourage frequent risk resolution events (production releases).</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIJKrf8x2rfsFJY3a2fKjhxslh4F-3CrtWb17jSCrgrPdJXB8DzDJON2FM3l7mY4MHB2tTroJnGybM5CZ_u-Gv0IX4fZmnNLERqSPXPQfZot_T90UNzLmADqWLBRzHou6PLl182m0znfs/s1600/Financial-Risk-Management-293x300.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="300" data-original-width="293" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIJKrf8x2rfsFJY3a2fKjhxslh4F-3CrtWb17jSCrgrPdJXB8DzDJON2FM3l7mY4MHB2tTroJnGybM5CZ_u-Gv0IX4fZmnNLERqSPXPQfZot_T90UNzLmADqWLBRzHou6PLl182m0znfs/s1600/Financial-Risk-Management-293x300.jpg" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
7. Percentage of time set aside for learning and improving current work. People need time set aside to learn and to improve their own work processes. We want to make that explicit as part of any transformation.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEis7ru8gXWF7Jz0tRZJHy1wCF2UV04B64vpWtGfgC2EDuUCD_YEKN5yMCEcuUy8zU-RFGjpRKkMu4js1L4MG8edMJBzq9gcKflBJYmoIThRvPZDqmTuOk-7k2HCCV_4WuUdueaWPvIJ0Uw/s1600/MobProgrammingIntro.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="795" data-original-width="1600" height="197" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEis7ru8gXWF7Jz0tRZJHy1wCF2UV04B64vpWtGfgC2EDuUCD_YEKN5yMCEcuUy8zU-RFGjpRKkMu4js1L4MG8edMJBzq9gcKflBJYmoIThRvPZDqmTuOk-7k2HCCV_4WuUdueaWPvIJ0Uw/s400/MobProgrammingIntro.jpg" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
8. Hours of manual work. By manual work, we mean repetitive manual tasks. This is the kind of work that can eat a lot of time and also drains people of their creativity and energy. Eliminate it, automate it, just don't ignore it.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuIS1HUYnusl-e45klbk4fmV86wn-2DE0Xflo9l-z7SnoIbbfTzRRh137FeQjkCrEv-hBfyQFXanlfOVul-WU9TPgVTx-IGDuvINfnrxRfV5ov26mnfy90sEbUO235fumk4nMjYVcO-D0/s1600/tedium.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="142" data-original-width="355" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuIS1HUYnusl-e45klbk4fmV86wn-2DE0Xflo9l-z7SnoIbbfTzRRh137FeQjkCrEv-hBfyQFXanlfOVul-WU9TPgVTx-IGDuvINfnrxRfV5ov26mnfy90sEbUO235fumk4nMjYVcO-D0/s640/tedium.jpeg" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
9. <span style="font-family: inherit;">Number of inter-team dependencies.
This is a count of the teams you must coordinate with before deploying your
code to production. In a perfect world you would have total freedom to deploy
non-breaking changes whenever they’re ready.</span></div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: inherit;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihSIYIGpSRRT6kRbTCqnhuoxhLg_og91A-NHUZhOH__vB8M0yxCll0wRx9uLy1A2kPHsbCfrMhZVW8OZQ4wJ9KMmfX6auaLQPBO7MQhgzkdSd_Y8fQAZ15vjDPaGKensQknd8AP5TB3FY/s1600/Coordination.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="672" data-original-width="673" height="319" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihSIYIGpSRRT6kRbTCqnhuoxhLg_og91A-NHUZhOH__vB8M0yxCll0wRx9uLy1A2kPHsbCfrMhZVW8OZQ4wJ9KMmfX6auaLQPBO7MQhgzkdSd_Y8fQAZ15vjDPaGKensQknd8AP5TB3FY/s320/Coordination.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
10. Number of after hours calls and emails. People need time to refresh and sending after hours work emails sends the wrong message. If we need 24/7 coverage, we must staff for it.</div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: inherit;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_yA39b8EJ6Qxas741pb8KuTFsvXCcDL71u23lCpPt7GtNm6uxplpSimVITWRSVDENOuYMs9vmvcNJz_CdnT_D7ezEeS5agS8ZZ-UO2h8SjvvVjETdI-aPrY1XqOIKqvynFv0rZx5jgm0/s1600/AfterHours2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="395" data-original-width="626" height="201" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_yA39b8EJ6Qxas741pb8KuTFsvXCcDL71u23lCpPt7GtNm6uxplpSimVITWRSVDENOuYMs9vmvcNJz_CdnT_D7ezEeS5agS8ZZ-UO2h8SjvvVjETdI-aPrY1XqOIKqvynFv0rZx5jgm0/s320/AfterHours2.jpg" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: left;">
<span style="font-family: inherit;"><br /></span></div>
<div class="separator" style="clear: both; text-align: left;">
I am hopeful that giving transformation managers something to measure that makes the environment more supportive of agility will be a useful and effective lever in the work we do. Please share your thoughts with me on twitter at @mikeonitstuff</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
PLEASE NOTE - These graphics are from a stock service for the most part and the one about deployments is problematic. If you created any of them, let me know and I will happily credit.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Thanks for reading -- Mike</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com1tag:blogger.com,1999:blog-6845215548869960100.post-24221117622725855332018-01-15T14:05:00.001-06:002018-01-15T14:05:36.200-06:00Hierarchy of Software Development needsIn reading <a href="http://cognitive-edge.com/blog/a-sense-of-direction-2-2/" target="_blank">Dave Snowden's article</a> on a sense of direction, I was reminded of my experience several years ago working as a Patient Care Tech at <a href="https://www.uabmedicine.org/locations/uab-hospital" target="_blank">UAB</a>. I had started volunteering there and then took a part time job to gain some clinical exposure and decide if I wanted to make a career change into nursing - turned out I did not.<br />
<br />
Anyway, I worked in the Emergency dept. which was a level one trauma unit. A trauma call is a complex thing. Injuries are often hidden and severity can vary wildly even with patients that present with similar injuries and histories.<br />
<br />
There are some basics of course. Airway, Breathing, Circulation - if you don't get those right it does not matter how well you set the bones or if you stitched up the cuts in a way the won't leave a scar.<br />
<br />
There are some corollaries in the world of Agile. They could be Build, Test, Deploy - if you can't build, without breaking stuff, and deploy it for use - the color selection and button placement don't matter. Like, at all.<br />
<br />
After a patient is breathing reasonably and holding their blood in, a team can worry about things like blood chemistry, organ and brain injuries, broken bones and abrasions.<br />
<br />
Similarly, when a team can routinely and safely deliver software for production use, they can start worrying about what features to deliver, in what order and how to manage that work.<br />
<br />
Scaling the management framework might be kinda like taking up a new hobby after a full recovery.<br />
<br />
<br />
<br />
<br />Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-67878432503724595722018-01-12T09:34:00.003-06:002018-01-12T10:29:20.491-06:00My guidepostsWhen I talk about Organizational Transformations or Agile Transformations, I am talking about the engagements as I usually see them. Some company - often a market share leader in their industry - wants to be more like what they imagine Google, or Facebook to be. They talk to their consulting supplier of choice or maybe several and decide on a framework to become Agile and awesome.<br />
<br />
By the time I come along, there's usually a project plan - sometimes disguised as a backlog - that includes milestones and payment triggers etc. There will be planning meetings and a sorting of the workers to become agile teams of one type or another, decisions about whether a particular function should use scrum or kanban, whether we should use Jira or Rally, how many columns to represent todo, doing, done etc.<br />
<br />
What's often missing is the universal understanding of why we're doing this and what we hope to accomplish. This often leads to <a href="https://ronjeffries.com/articles/016-09ff/defense/" target="_blank">dark scrum</a> and a general sense that the people in charge and the consultants they've hired are full of shit.<br />
<br />
I assume the point of these engagements is to become capable, high performing, learning organizations that delight customers and take all the market share from their lesser competitors. The goal of the exercise is not to become good at performing the ceremonies and practices of any framework or method - methods and practices are probably necessary, but are not sufficient.<br />
<br />
Here are some things that I think are important:<br />
<br />
<ul>
<li>Increase capacity/capture value everyday - any day might be the last day for the project.</li>
<li>We should never be one-deep in a skill or position - people should be able to go on vacation or take a promotion without leaving a gaping hole.</li>
<li>We must be able to make a simple software change to production in one day - shorter is better.</li>
<li>Teams must be capable of independent action - if three teams are required to make a change to your three tier app, you gotta fix that.</li>
<li>Teams have discretion and authority for their work - keep friction and approval processes down</li>
<li>No out-of-band reporting - the natural by-products of the activity must tell the story. </li>
<li>You must always know what your apps are doing - I never want to learn from a customer call or twitter that our website acting weird - same for internal apps.</li>
<li>Every component or activity must fight for it's life - extra is extra if it's dumb get rid of it.</li>
<li>We should always minimize complexity where we can - Keep your stack short.</li>
<li>No resume driven development - we'll make time for learning and playing.</li>
<li>Keep up with the tech - play with the cool stuff enough to know if/when to adopt it.</li>
<li>Working here should make you more marketable - learn and grow, I'll help.</li>
<li>Behave - nobody wants to work with a jerk and they don't have to.</li>
<li>It's not OK to suck - if what we do sucks, we have to fix that.</li>
</ul>
There are other things of course but these are the big ones for me.<br />
<br />
Thanks for reading - MikeMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-12741051364207918092018-01-11T17:47:00.001-06:002018-01-11T17:47:26.221-06:00More thoughts on Organizational TransformationMy post yesterday generated some good criticism and discussion on Twitter. One of the common misunderstandings was the idea that I advocate the cascading of explicit goals down the organization.<br />
<br />
This is exactly what I was trying to avoid. I am questioning now my proficiency in the language...<br />
<br />
Anyway, when I said goals at each level inform the goals at the next next level, I created confusion. I'll try to clear things up a bit with some examples below.<br />
<br />
I might have a goal (desired outcome) of reducing the company's travel spend by 50%. If I think I have all the answers, I could ban all travel for a period of time or create an onerous approval process. Both options that reveal my lack of regard for others in the organization and my arrogance.<br />
<br />
Alternatively I could broadcast the goal - we need to spend half as much on travel - and some visibility into current spend vs. the baseline. After that I would leave it to those spending the money to figure out how to reach the target. They might prioritize travel, book flights earlier, use AirBnB instead of the W - lot's of options for most companies to spend less especially in the short term.<br />
<br />
I have a goal that I want a simple software change to go from identified by the business to safely in production in half the time it takes today. I could specify Scrum, require unit test coverage, and demand a CI/CD pipeline - or - I could broadcast the goal and let the people closest to the work decide how best to reach it.<br />
<br />
There might still be problems with this approach and it may be useful only in an ordered system - but I want to at least dispel the idea that I advocate passing detailed requirements or squishy objectives down through the layers of an organization.<br />
<br />
What I want to do is increase the amount of information about organizational direction while also increasing self-organization and autonomy.<br />
<br />
Goals or vector signalling will be vague and often frustrating for the people doing the work - that lack of detail coupled with a measurable outcome leaves room for creativity and discovery.<br />
<br />
Thanks for reading - MikeMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-43966744726900291232018-01-10T18:18:00.000-06:002018-01-10T18:18:03.480-06:00Thoughts on Organizational TransformationMy current thoughts on Organizational Transformation wherein I propose a simple repeating pattern of self-organized, autonomous, independent teams at every level of the enterprise under change.<br />
<br />
We’ll start with some definitions to aid in subsequent discussion:<br />
<br />
<br />
<ul>
<li>Team - any group of people working together toward a goal or set of goals</li>
<li>Goal - a desired, measurable outcome resulting from the work of a team or teams</li>
<li>Product - a tangible artifact produced by a team to be used by consumers</li>
<li>Service - a process carried out by a team at the request of a consumer</li>
<li>Consumer - a person or team that uses products and/or services</li>
<li>Outcome - Movement in a business metric or situation</li>
</ul>
<br />
Before starting any transformation it’s very important to understand and articulate the desired outcomes of the effort.<br />
<br />
Because so many of these engagements are IT driven I’ll use a IT example:<br />
<br />
<ul>
<li>Enterprise X wants to compete and win in our industry.</li>
<li>IT strives to eliminate friction for product teams using IT so they can quickly, safely and economically design, develop and support business capabilities through changes to existing systems and creation of new systems.</li>
<li>Marketing will improve on our our ability to...</li>
<li>HR must make it easy for...</li>
</ul>
<br />
With a clear goal in mind we can bring together the team to determine:<br />
<br />
<ul>
<li>What services and capabilities to provide?</li>
<li>What activities to continue or start?</li>
<li>What activities to stop doing?</li>
<li>Who are our customers?</li>
<li>How will we measure the outcome?</li>
</ul>
<br />
The services and capabilities listed at each level in the organization are usually decomposed at the next level down until they are actually implemented.<br />
<br />
This provides alignment from the top level transformation goal, through the intermediate goals of each department all the way to the individual contributor executing a task.<br />
<br />
Team members at one level are likely to support a team at the next level. So a VP on the CTO’s team at the IT department level has a team of directors and managers that decompose an IT function such as security or cloud infrastructure into smaller pieces for their teams to implement.<br />
<br />
Each team, regardless of level, is self organizing, autonomous, and as independent as possible. They are also intensely customer focused whether their customer is another team using their product, a business function requesting new or changed software, or a Director trying to understand and align with executive guidance.<br />
<br />
Thanks for reading - Mike<br />
<div>
<br /></div>
Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-36866998619398305182017-10-23T05:18:00.002-05:002017-10-27T08:43:46.867-05:00Give your stories an expiration dateMy wife will tell you that I am a hoarder. There's room between my fence and the forest behind my house where I 'store' things we might want to have later.<br />
<br />
I say that to let you know - I get why people don't want to throw good stuff away.<br />
<br />
Still, I think there's a really good case for adding a Time To Live value to our backlog items. The problem with a backlog - especially those in Jira and similar products is that it seems easy to keep a large number of items. It seems practically free or at least very cheap.<br />
<br />
There are these hidden costs though.<br />
<br />
Management overhead: When I have a lot of stories I feel compelled to look through them all to make sure I'm not missing something important that should be moved up in priority. If there is high priority work lurking in the depths of my backlog, I must not being paying attention.<br />
<br />
Undue Attatchment: I really love some stories. I had the idea, wrote it down, maybe thought up some acceptance criteria and then - nobody cared. I keep the story around because it just seems like a great idea to me. Not only that but I put work into it and don't want to lose that work. Here's the thing, if it's really a good idea it will come back, maybe more than once, in a better form that somebody besides me cares about.<br />
<br />
Distraction: Sometimes teams feel obligated to get through the list and will take on stories, not because they seem useful but because they are the right size to fill out a sprint. There's almost undoubtably a better use of that capacity.<br />
<br />
I prefer a small backlog - maybe 2-3 iterations worth - of stories that I and the team feel urgency about. Iteration planning should be about the highest priority work not about filling capacity.<br />
<br />
If your story goes more than a couple of iterations without making the cut - kill it. The truly good ideas will percolate and come back better when the time is right.<br />
<br />
Thanks for reading - Mike Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-89166038861732864602016-08-19T11:12:00.001-05:002016-08-19T13:00:35.038-05:00<div align="center" class="MsoTitle" style="text-align: center;">
<span style="font-size: x-large;">Refactoring the
Enterprise</span></div>
<h1>
<span style="font-size: large;">Why Refactoring – Is this yet another Agile Method</span><o:p></o:p></h1>
<div class="MsoNormal">
First, this is not a call for another Agile Method.<span style="mso-spacerun: yes;"> </span>I won’t try to write a book and repackage a
bunch of stuff you already know and then offer to certify you.<span style="mso-spacerun: yes;"> </span>Nothing wrong with that but not my
thing.<span style="mso-spacerun: yes;"> </span>Second, I am using Refactoring
because I have been recently re-inspired by doing refactoring katas thanks to
<a href="http://llewellynfalco.blogspot.com/" target="_blank">Llewellyn Falco</a> and <a href="http://zuill.us/WoodyZuill/" target="_blank">Woody Zuill</a> and reading some great books <a href="https://pragprog.com/book/rjnsd/the-nature-of-software-development" target="_blank">The Nature of Software Development</a> by <a href="http://ronjeffries.com/" target="_blank">Ron Jeffries</a> and <a href="http://shop.oreilly.com/product/0636920033158.do" target="_blank">Building Microservices</a> to name two. What I describe below is similar in some ways
to refactoring legacy code.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I have been talking about this idea of carving out a bit of
business capability that a single team can deliver and run without the need to
coordinate with other teams. The fancy name for this is Domain Driven design
with Bounded Context. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Most businesses these days, regardless of the product or
service they deliver, have become software development companies. Many of these
companies are running a fragile, organically grown, <span style="color: black; mso-themecolor: text1;">or acquired</span>, collection of code and infrastructure
that is difficult and risky to change. At the same time, market demands,
competition, and a changing technology landscape make business agility more
important than ever.<span style="mso-spacerun: yes;"> </span><o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
There are already some enterprise frameworks for agile but
they feel heavy to me and they seem to put the focus on detailed upfront
planning and ongoing processes which seems inconsistent with the Agile
Manifesto. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I think a refactoring approach can be used to transform
organizations in an iterative, emergent way that limits risk and maximizes long
term ROI.<span style="mso-spacerun: yes;"> </span>Here’s what that might look
like.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Meet with executives at any level in the organization to
understand their strategic objectives and known barriers to achieving them. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]--><span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span><!--[endif]-->A strategic objective might be to provide device
specific, yet consistent access to product information. <o:p></o:p></div>
<div class="MsoListParagraphCxSpLast" style="mso-list: l0 level1 lfo1; text-indent: -.25in;">
<!--[if !supportLists]--><span style="font-family: "symbol"; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font: 7.0pt "Times New Roman";">
</span></span></span><!--[endif]-->A barrier to achieving that might be that the
business rules are embedded in the webpage code and backend systems without a
clear delineation. Creating a mobile app that provides the same selection and
pricing as the existing website could be very expensive and require a huge
amount of testing with a long time line.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Enterprise and Solution Architects are in the best position
to identify challenges and opportunities in the IT space that align to those
objectives and remove barriers. The architects will also have a key role in
integrating new services into the existing architecture.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Because we must be able to deploy at any time – even
multiple times per day - organizational leaders must clear a path for a
parallel delivery pipeline that allows on demand deployment to production
environments. Versioning and feature flags allow partial feature upgrades and
multiple versions of software to coexist in the production environment.<span style="mso-spacerun: yes;"> </span>Creating a parallel delivery path allows the
lights to stay on while we iterate to the fully workable solution.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
One way to start the journey would be to select a specific
business capability that needs to change, or scale, but is difficult or risky
in the current process. After creating the bounded context; design a product
that provides that business capability to customers – who may be internal or
external.<span style="mso-spacerun: yes;"> </span><o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
For our example above we might create a service that
encapsulates the business rules and the product data to determine which
products should be offered to a customer. The service could be called via a restful
interface that includes specific selection criteria.<span style="mso-spacerun: yes;"> </span>The service would return a list of products
(prices might be included or might be provided by a different service.) The
development team for each device platform could decide how best to display the
offerings.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
To get started on the new service we would form a product
team (Product Owner, Developers) that will develop and support the product
starting with the smallest useful feature set, MVP, in parallel with the
current delivery scheme. The <span style="color: black; mso-themecolor: text1;">Developers
are</span> responsible for testing and supporting their product – even in
production.<span style="mso-spacerun: yes;"> </span>The Product Owner is
responsible for maximizing value and being available to the team at all times –
What Woody calls Decision Queue Time – can easily multiply the time to value
for a development effort.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
To ensure the business agility we promise, it’s not enough
to just write the software. The product team must be able to deliver running
tested features into production on their first iteration.<span style="mso-spacerun: yes;"> </span>This means they need to have version control,
build automation, acceptance test automation, <span style="color: black; mso-themecolor: text1;">non-functional test automation, </span>and automated
deployment from the very beginning. Assign a Coach to help with these things
and the ongoing challenges they will face.<span style="mso-spacerun: yes;">
</span>The first running tested feature may be as simple as “Hello World” but
it will be in version control, have been automatically built, passed its
acceptance tests, <span style="color: black; mso-themecolor: text1;">passed
non-functional requirements testing, been automatically deployed into the</span>
production environment, and validated as available and responsive. This is the
proof that all the parts work together and it’s a great way for the team to
experience the definition of done.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
It is important to make clear the expectation of excellent
technical practices.<span style="mso-spacerun: yes;"> </span>Release to
production every iteration using automated tests and automated
build/deploy.<span style="mso-spacerun: yes;"> </span>Version APIs and use
feature flags as required to enable trunk based development.<span style="mso-spacerun: yes;"> </span><span style="color: black; mso-themecolor: text1;">Design
and </span>build in monitoring, high availability, recovery, graceful
degradation, and scaling from the beginning. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Also, every developer must be familiar with and responsible
for the quality of every piece of code. This is a key risk mitigation<span style="color: red;"> </span><span style="color: black; mso-themecolor: text1;">strategy;</span><span style="color: red;"> </span>nobody wants to worry about crucial code that only
one person can work on or complex code that fights modification.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
This approach provides learning early and often but still
requires patience. The first effort will be slow – people will need training
and experience.<span style="mso-spacerun: yes;"> </span>There will be missteps
and disappointment along the way.<span style="mso-spacerun: yes;">
</span>Understand and plan for this – you have already reduced risk by
undertaking this as a parallel effort to whatever process is already in place
and by automating tests and deployment.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
We started off talking about an enterprise transformation
but we’ve only talked about a single team so far. In the spirit of the agile
manifesto we want to iterate and learn. When the first effort starts to show
success, add another product and team.<span style="mso-spacerun: yes;">
</span>Use this pattern of adoption until you run out of products and markets
that need attention.<span style="mso-spacerun: yes;"> </span>Your organizational
structure will change over time to reflect the new architecture.<span style="mso-spacerun: yes;"> </span>Many teams will be able to support more than
one related product – that will emerge as you go.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Changing the focus from the activities of Agile/DevOps
adoption to the achievement of strategic business objectives through
refactoring allows us to start learning faster and to stop at any time with
minimal waste. Moving to a product focus allows us to leverage Conway’s law in
reverse to transform the organizational structure around the business outcomes
we are trying to create.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I am interested in your feedback especially if you have
specific examples and ideas on why this could never work in the complex domains
of the real world.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Thanks for reading --Mike<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<br /></div>
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:RelyOnVML/>
<o:AllowPNG/>
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml><![endif]-->
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-US</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="false"
DefSemiHidden="false" DefQFormat="false" DefPriority="99"
LatentStyleCount="381">
<w:LsdException Locked="false" Priority="0" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 9"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="header"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footer"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index heading"/>
<w:LsdException Locked="false" Priority="35" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of figures"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope return"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="line number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="page number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of authorities"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="macro"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="toa heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 5"/>
<w:LsdException Locked="false" Priority="10" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Closing"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Signature"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="true"
UnhideWhenUsed="true" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Message Header"/>
<w:LsdException Locked="false" Priority="11" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Salutation"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Date"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Block Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Hyperlink"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="FollowedHyperlink"/>
<w:LsdException Locked="false" Priority="22" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Document Map"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Plain Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="E-mail Signature"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Top of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Bottom of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal (Web)"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Acronym"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Cite"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Code"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Definition"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Keyboard"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Preformatted"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Sample"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Typewriter"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Variable"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Table"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation subject"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="No List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Contemporary"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Elegant"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Professional"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Balloon Text"/>
<w:LsdException Locked="false" Priority="39" Name="Table Grid"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Theme"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Level 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Level 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Level 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Level 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Level 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Level 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Level 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Level 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Level 9"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" QFormat="true"
Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" QFormat="true"
Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" QFormat="true"
Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" QFormat="true"
Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" QFormat="true"
Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" QFormat="true"
Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" SemiHidden="true"
UnhideWhenUsed="true" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="TOC Heading"/>
<w:LsdException Locked="false" Priority="41" Name="Plain Table 1"/>
<w:LsdException Locked="false" Priority="42" Name="Plain Table 2"/>
<w:LsdException Locked="false" Priority="43" Name="Plain Table 3"/>
<w:LsdException Locked="false" Priority="44" Name="Plain Table 4"/>
<w:LsdException Locked="false" Priority="45" Name="Plain Table 5"/>
<w:LsdException Locked="false" Priority="40" Name="Grid Table Light"/>
<w:LsdException Locked="false" Priority="46" Name="Grid Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="Grid Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="Grid Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="46" Name="List Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="List Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="List Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Mention"/>
</w:LatentStyles>
</xml><![endif]-->
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Calibri;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]-->
<!--StartFragment-->
<!--EndFragment--><br />
<div class="MsoNormal">
<br /></div>
Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-30027609069318745462016-07-30T19:30:00.000-05:002016-07-30T22:23:39.134-05:00<h2>
Strong Pairing, Mobbing, and Woody's Workshop</h2>
<div>
First - some background.</div>
<div>
<br /></div>
<div>
I don't program computers for a living and haven't in a long time. I am interested in programming techniques, languages, and approaches though; I <b>could</b> code my way out of paper bag if my life depended on it.</div>
<div>
<br /></div>
<div>
For a long time I have been a proponent of XP practices like pair programming, TDD, small stories, frequent delivery, etc. </div>
<div>
<br /></div>
<div>
At my last company I had started to sit with developers while they worked and talk with them about some of the issues they faced. General problem solving, simplifying, and helping to focus on one thing at a time. This would be very weak pairing as I would be conversant but not fluent in the tools.</div>
<div>
<br /></div>
<div>
At the same company, two of the teams had started to do a lot of group sessions where they would work through problems and solutions together in an informal way that allowed people to join and leave as they needed to while the group continued to make progress. We didn't have a name for it but it seemed to work well. This had grown out of our hiring process where all available members would participate in interviews and technical challenges that required collaboration, resourcefulness, and the courage to ask questions and sometimes say "I don't know."</div>
<div>
<br /></div>
<div>
A few months ago on the AgileMentoring.com Slack board, somebody mentioned Mob Programming which I had not heard of. I was very interested though based on the previous good experience with group sessions, and intrigued by some of the details such as frequent driver changes.</div>
<div>
<br /></div>
<div>
I watched the <a href="https://www.youtube.com/watch?v=p_pvslS4gEI" target="_blank">video</a>, bought the <a href="https://leanpub.com/mobprogramming" target="_blank">Mob Programming book</a> and reached out to Woody on Twitter. We had a phone call one Sunday afternoon and I decided I needed to learn as much as possible about this way of working.</div>
<div>
<br /></div>
<div>
Cut to #Agile2016 and an available Mob Programming workshop in Atlanta after the conference. While walking around and talking to a large number of interesting people, I noticed there was a Mob in session working on a <a href="http://llewellynfalco.blogspot.com/2016/07/5-ways-to-do-decision-trees-in-c.html" target="_blank">Refactoring Kata for a simple Tennis Scoring program</a>.</div>
<div>
<br /></div>
<div>
I walked over and sat down to observe. In the space of less than 10 minutes, several approaches to refactoring the ugly If block were coded. All of them worked but left one or another team member dissatisfied because they were clever, or confusing, or ugly, finally - still in the 10 minutes or so - somebody suggested a clean, simple, and elegant solution. The tests passed and it was over.</div>
<div>
<br /></div>
<div>
<a href="http://llewellynfalco.blogspot.com/" target="_blank">Llewellyn Falco</a> mentioned that they would be doing another Kata as a Mob the next morning. Well the next morning the projector had disappeared and there had been a party the previous night so only Llewellyn and I showed up. He offered to do a <a href="http://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html" target="_blank">Strong Style Pairing</a> session with me. Strong Pairing is where any coding idea must go through somebody else's hand on the keyboard. I was a bit nervous, we would be coding in C# - a language I have not used or even looked at - and with just the two of us there would be no cover for my ignorance. It turned out that Llewellyn was very patient, we came to a nice refactoring solution in a about 40 minutes with some good conversation and advice thrown in.</div>
<div>
<br /></div>
<div>
Shortly after that, I realized I was a train ride and car drive away from Woody's Mob Programming workshop. I arrived a few minutes late and Woody was still covering stuff that's in his book - whew!</div>
<div>
<br /></div>
<div>
Woody walked 4 volunteers through the rotation process while the rest of us tried not to interject and learned to feel what that is like.</div>
<div>
<br /></div>
<div>
In no time, we broke into groups of 4-5 - each with our own computer setup - and strict directions that only the current navigator could suggest what to code and only the current driver could type stuff in. </div>
<div>
<br /></div>
<div>
This was hard. As the navigator, I really wanted to consult with the team. As an observer, I really wanted to help the navigator. As the driver - all my recently learned keyboard shortcuts were useless because we were using a different IDE from what Llewellyn and I had used.</div>
<div>
<br /></div>
<div>
After satisfying a couple of requirements, we were allowed to call for a consult at any time and talk as group but with hands off the keyboard. This was a lot better, but we found it easy to spend too much time evaluating different ideas without putting them to code. A couple of times when we wanted to refactor because the code was getting ugly, we couldn't agree on an approach right away so we just made the test go green and put refactoring on the back burner. I did mention that we were doing TDD - right?</div>
<div>
<br /></div>
<div>
A quick word about TDD. With the group it was easy to write the test for each new requirement first. We quickly grew comfortable with this approach and it made refactoring attempts really easy and stress free. One time we made too many changes and turned about half our tests red. Woody had us revert until all the tests were green and try again. His view - which I now share - is that you should only start a refactoring when all your tests are green, and that you should never be more than a couple of edits between passing all tests.</div>
<div>
<br /></div>
<div>
Finally, as we continued to knock out requirements more and more quickly, and Woody - our product owner - was busy with other teams, we started to use the gaps to review our approach and identify refactoring opportunities that would make us happier with our code. Better names, cleaner tests, etc.</div>
<div>
<br /></div>
<div>
The last stage as a team was to be in full Mob mode - anybody could make a suggestion at any time while remaining Kind, Considerate, and Respectful. This was a lot of fun and we already felt like a team after something like <b>1 hour</b> of working together.</div>
<div>
<br /></div>
<div>
When we started only one person on the team was an actual C# programmer. This was scary but turned out to not matter. Almost any problem is going to require only a small set of language features and you learn the ones you need pretty fast. A nice side effect is that everybody learns them.</div>
<div>
<br /></div>
<div>
I also thought that the frequent Driver Rotation would be disruptive - we were using 4 minutes. It was not a problem and seemed to have the effect of time-boxing our work. We would think about how we could go green in the space of a rotation - whether it was a new requirement or a refactoring.</div>
<div>
<br /></div>
<div>
I want to do a lot more of this and find a really good way to Mob Remotely. I highly recommend that you get Woody to do a Workshop for your teams and give this a solid try. The concepts are simple but I think your chances of success and adoption go up with the workshop.</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-80345689329693504812013-09-22T15:59:00.000-05:002013-09-22T22:30:50.650-05:00The Mouse is dead - long live something elseMy wife came home with a new issue the other day. Kindergartners will take a pass on computer time rather than learn how to use a mouse. You might say - they're five, what are you talking about and who cares anyway. <br />
<br />
Well the thing is five year olds have, for the past several years, loved their computer time. So what's different this year? Tablets. Well Tablets and the <a href="http://smarttech.com/smartboard" target="_blank">Smart Board</a> which is like a wall sized tablet. The kids are completely unimpressed with with the abstraction of movement and selection required to use a mouse.<br />
<br />
So in the immediate future I think it's going to be touch, the guys at <a href="https://www.leapmotion.com/" target="_blank">leap</a> like hand waving and that might catch on, or it might have the same problem as the mouse for these kids - not direct enough.<br />
<br />
I can see a near future where something like <a href="http://www.google.com/glass/start/" target="_blank">Google Glass</a> is all I need. I'll tell Putty what window to open and the *nix aware voice recognition will take all the vowels out to make good command lines.Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-17794451034462314202011-12-03T07:32:00.001-06:002011-12-03T08:56:26.656-06:00Data Sharing Among Applications<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLVnweooIkEgDSUxF9ajop8WJocGrQDmbToBqHM7vEdzo9IYxVK0lx7UQ9rqmzq_Ix4gQwICTZnMZ81lPdgVsJ3lTSvrOqgHEzWnK9L49U71vIMb1C-7vzzgKmNPi_s2vYA9tsIPwBNSk/s1600/sharing.gif" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLVnweooIkEgDSUxF9ajop8WJocGrQDmbToBqHM7vEdzo9IYxVK0lx7UQ9rqmzq_Ix4gQwICTZnMZ81lPdgVsJ3lTSvrOqgHEzWnK9L49U71vIMb1C-7vzzgKmNPi_s2vYA9tsIPwBNSk/s320/sharing.gif" width="320" /></a></div>
<span class="Apple-style-span" style="font-size: large;">Too Much Complexity - It's a big Pain In My Ass</span></div>
<div>
<br /></div>
I have this theory that most of the shit we do in IT is more complex than it needs to be There are entire industries built around creating new vocabularies for old concepts and packaging fundamental data processing concepts into new buzzwords - almost always making simple things less simple.<br />
<div>
<br /></div>
<div>
This is not new, it's been common practice for at least 15 years. I think prior to about 15-20 years ago there were too few IT pros to get away with it - we would call BS on your "new idea" if it was already commonly understood or too obvious.</div>
<div>
<br /></div>
<div>
Recently, I've been thinking of how to de-couple applications that have grown up organically as close siblings. You've seen this where each application has to have its own copy of the data from other apps. We have an institutionalized scheme for noticing changes and pushing them to all interested parties. Or where one application is doing complex multi-table queries against the physical tables in another application's database. Or even worse where my app consumes some of your data and changes the status of the records directly in your DB.</div>
<div>
<br /></div>
<div>
Many people don't seem to think this is a problem or even particularly ugly. I might just be a whiny old guy to think something more elegant would be better - maybe so but I'm gonna whine.</div>
<div>
<br /></div>
<div>
<span class="Apple-style-span" style="font-size: large;">Problems with close sibling applications</span></div>
<div>
<br /></div>
<div>
You're too much in my business. I mean where's the privacy? Where's the respect? And now I have to get your permission to re-arrange my furniture? I feel constrained. I feel put upon. We need to re-evaluate our relationship.</div>
<div>
<br /></div>
<div>
All this everybody's in everybody else's business mean it's really hard to make simple changes. I might break your app. You might break mine. Who uses what? What apps are at risk if I make this change? It's all very scary and leads to paralysis, delays, and really frustrated business stakeholders that just want to get shit done.</div>
<div>
<br /></div>
<div>
<span class="Apple-style-span" style="font-size: large;">Popular Solution Approaches</span></div>
<div>
<br /></div>
<div>
Generally you see a few approaches. One is to decide that the entire enterprise is going to implement some sort of Enterprise Service/Data bus and become SOA everywhere. Just a few million bucks on consulting, hardware, software, projects to create web services for all our apps, and we'll be good to go. Three years - tops.</div>
<div>
<br /></div>
<div>
Another approach is to undertake a CMDB project. We'll document all our dependencies, design a data store to put everything in and then we'll be able to see exactly what changes will affect what processes and applications. Again it'll only cost a few million bucks and we should be able to do this in no time - two or three years. Let's ignore for a moment that we have a poor understanding of our dependencies to somehow overcome.</div>
<div>
<br /></div>
<div>
For both of these you also have to ignore that the business still wants to get shit done and they compete for the resources you're using on these "nice to have" IT initiatives. They compete using business cases with revenue, presented by professional sales people.</div>
<div>
<br /></div>
<div>
In the old days we had the idea that there should be an enterprise database - a single, shared, easily accessible database that everybody would use. We would define every data element in the data dictionary and if your app needed to have last names, you would go to the data dictionary to find out that last names are always varchar(25) or whatever. Of course this was a complete failure, with data dictionaries having at least as many definitions for a standard last name as there were existing applications that use last name. The idea is still attractive - but it just does not work in the real world.</div>
<div>
<br /></div>
<div>
My opinion is that these approaches are too complex to undertake as a project and are doomed to failure - I would love to hear some success stories though.</div>
<div>
<br /></div>
<div>
<span class="Apple-style-span" style="font-size: large;">What we can start doing now</span></div>
<div>
<br /></div>
<div>
I'm also a big fan of Fundamentals - setting a pick, getting down on the ball, looking where you want to go - before advanced techniques like driving to the basket, turning a double play, and getting a knee down.</div>
<div>
<br /></div>
<div>
So I suggest starting with something simple. One or two apps at a time, find out what data they share and how. </div>
<div>
<br /></div>
<div>
If they're doing queries directly against your tables - move that to a view that also does whatever joins are required to give them the data set they need. Think about things like - my app looks for a record in one table and if it's not found, queries a history table for the same info - could you create a view that allows me to look just once?</div>
<div>
<br /></div>
<div>
What if I need to change values in your data? First explore whether that's really needed, if it is, create a stored procedure that you control and I just call. Then you are free to do whatever you need in your app as long as my view and update procedure stay the same - you don't even need to talk to me about it...</div>
<div>
<br /></div>
<div>
After this first step of creating Views and Procedures we can start thinking about creating endpoints. Web Services, an intermediate Database server that Federates access without replicating data (use a data warehouse to Federate big data), or whatever other endpoint you can think of.</div>
<div>
<br /></div>
<div>
<span class="Apple-style-span" style="font-size: large;">Views? That's so 1990 - we are SOA all the way XML, HTML...</span></div>
<div>
<span class="Apple-style-span" style="font-size: large;"><br /></span></div>
<div>
Views are an enabler that support whatever you want to do next while providing immediate benefits - not the least of which is figuring out what data you actually share.</div>
<div>
<br /></div>
<div>
Views might be 1990 but just about everybody can understand a select statement. And think about the benefits to testing. Rather than needing a full blown environment with all the services up and running. Or mocking all those services. I can have test data in a Spreadsheet or Access or MySQL or whatever I want and simply point the app to the datasource. I can also peruse the data that my app sees without having to know all about the schema in the source DB.</div>
<div>
<br /></div>
<div>
<span class="Apple-style-span" style="font-size: large;">Conclusion</span></div>
<div>
<span class="Apple-style-span" style="font-size: large;"><br /></span></div>
<div>
It's our job to resist gratuitous complexity. Go to the fundamentals that enable whatever is next and only add moving pieces that can carry their weight and more.</div>
<div>
<br /></div>
<div>
Thanks for reading - Mike</div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<span class="Apple-style-span" style="font-size: large;"><br /></span></div>
<div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<span class="Apple-style-span" style="font-size: large;"><br /></span></div>Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-23027309773693513212011-01-13T13:17:00.000-06:002011-01-13T13:17:35.693-06:00Turnaround Toolbox - Set Scope and Accountability for the teamHaving explored what everybody thinks we should do - <a href="http://mikeonitstuff.blogspot.com/2010/12/turnaround-toolbox-learning-current_31.html">Expectations</a> - and getting control of how folks engage us - <a href="http://mikeonitstuff.blogspot.com/2011/01/turnaround-toolbox-define-limit-and.html">Inputs</a> - it's time to set the scope for the team. <div><br />
</div><div>Scope includes all the tasks we do, products we deliver, and also what we're accountable for.</div><div><br />
</div><div>Tasks and Deliverables: </div><div>For each task your team does and deliverable you produce, you need to know the Who, What, Where, When, Why, and How. </div><div><br />
</div><div>Who on the team does the work? If the task is one-deep, who would provide secondary, and tertiary coverage? A lot of times you find these little one off items that one person knows about and knows how to do. If it's going to stay in your box, you must be able to support it through vacations, resignations, etc. Counting on a single person is an unacceptable risk.</div><div><br />
</div><div>What is the task? Is it an operational procedure, document creation, external communication? Categorizing the What of items makes it easier to organize them for documentation and assignment.</div><div><br />
</div><div>Where does the activity occur? What you want to understand here is whether it's location specific. Manning a teller window in a bank is location specific. Creating a spreadsheet from a report can probably be done anywhere.</div><div><br />
</div><div>When and with what frequency does the activity happen - or need to happen? You might find that you have tasks at a frequency that you're not staffed for. For instance 24/7 operational monitoring without 24/7 staffing. It might still stay in your scope, but with a different How component. </div><div><br />
</div><div>Why do you do it? Everything must be supported by a compelling reason - everything you do comes at a price. Arriving at the cost can be difficult when nobody has to write a discrete check for the item, but it's important to get some idea. Is it a good value? Does it mitigate a risk? Does it meet a contractual or regulatory requirement?</div><div><br />
</div><div>How is it done? If we don't have documentation we'll need it - either to keep the task, or to transition it to a more appropriate home. </div><div><br />
</div><div>A few words about accountability. If it's in your box, you are accountable for it. Given that, you want to make sure that you have control over everything in your box. This means you must push out stuff where you're just the middle man. Being the middle man is fine if you add some value and you limit your accountability to your performance as the middle man. </div><div><br />
</div><div>The most important thing is that you do not want to end up accountable for things you cannot control. So if your job is to <b>predict</b> or <b>report</b> on the sunrise - that's fine - if somebody expects you to <b>control </b>the sunrise - well that's a recipe for disappointment.</div><div><br />
</div><div>So, figure out what your team should do, make sure you can perform, and limit your accountability to things that you can control.</div><div><br />
</div><div>Thanks for reading - Mike</div>Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-78131935534766872722011-01-04T06:44:00.004-06:002011-01-04T07:19:54.697-06:00Turnaround Toolbox - Define, Limit, and Enforce your inputs<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfZ-CewqCGymlGSEfPdPGnajo_rexmwrGNFowQCFvpuyxjTzl7h9uMDseZUbi0KtTgzvg3mFLLnMdS3npUkIwUKJAwrtzTvI75yMyGQXAIRNXCC2Xdbqu1UgGFHG54M5MtnzDCh33sRFE/s1600/Border+patrol.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="148" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfZ-CewqCGymlGSEfPdPGnajo_rexmwrGNFowQCFvpuyxjTzl7h9uMDseZUbi0KtTgzvg3mFLLnMdS3npUkIwUKJAwrtzTvI75yMyGQXAIRNXCC2Xdbqu1UgGFHG54M5MtnzDCh33sRFE/s200/Border+patrol.jpg" width="200" /></a></div>In the last post I talked about <a href="http://mikeonitstuff.blogspot.com/2010/12/turnaround-toolbox-learning-current_31.html">Expectations</a>. Today I want to talk about getting control of the inputs. It's really hard to provide good customer service if you take requests via multiple, uncontrolled channels. Think about trying to grocery shop to a budget with random people throwing stuff in your buggy at random times - you could probably keep track of most of it, but that ipod touch from the electronics department would be a painful miss when you got to the register.<br />
<br />
We've all had experience with a lot of input channels - email, IM, telephone, one or more ticketing system, scheduled tasks, etc. Any or even all of these together can work if you have a process in place to manage and track them. Some organizations even take tweets now. The key is getting control so that nothing falls through the cracks.<br />
<br />
<span class="Apple-style-span" style="font-size: large;">Define your inputs:</span><br />
<br />
<b></b>If you take <b>email</b> does it go to individual in-boxes, an organizational in-box, or a distribution list? Who is responsible for keeping track of the requests? How are items assigned? Do responses come from individuals or from an organizational sending address? What happens when somebody goes on vacation? I am not a fan of taking requests via email because there are just so many cracks for things to fall into. I get hundreds of emails a day and the signal to noise ratio is not very good. But it might be a different story for you so if email works use it; you still must define how you are going to handle email requests.<br />
<br />
<b>Instant messaging</b> would seem to be an even harder nut to crack than email, in my experience IM provides a natural indicator for immediate requests - if I don't respond to your IM you can be pretty sure I am not working on your issue. IMs don't work as well for problems that require more time or coordination. Much like a phone call, once we quit talking, I am on to something else and your issue is a fast fading memory.<br />
<br />
<b>Phone calls</b> - see IMs. Good for immediate stuff but once we hang up it is over.<br />
<br />
I like some sort of <b>ticketing system </b>something like Fogbugz that is easy to use like email but keeps track of ownership, history and related artifacts is nice. Salesforce works as well as a lot of others. It does not matter so much which system you use as long as you use one. Ticketing systems give the issue a unique handle that people can refer back to, use as a license to work, and do reporting on. Try to avoid multiple disconnected systems though.<br />
<br />
<span class="Apple-style-span" style="font-size: large;">Limit your inputs:</span><br />
<b><br />
</b><br />
Only take requests via inputs you have defined and can manage. This should be obvious but I can tell you from experience that it is not. People that want stuff from you will use any path they can, but they will crucify you when their request falls into the Grand Canyon sized crack in the <u>"interupt an ongoing hallway conversation to mention this little item"</u> method of request input. If you have a process for managing requests via Tweets, Email, Tickets, and Phone Calls then go ahead and takes requests through those channels - just don't take requests through Facebook Wall Posts until you figure out how to manage them to completion and get that defined for your customers and staff.<br />
<br />
<span class="Apple-style-span" style="font-size: large;">Enforce your inputs:</span><br />
<b><br />
</b><br />
This is both the most difficult and most important, especially if the team has historically taken requests however they come in. When you first start enforcing your inputs with customers it can seem like they're getting the run-around. You want to avoid this by gradually moving from taking the requests as you always have to only accepting requests through the defined channels. It's a journey.<br />
<br />
At first I will start with some canned language that tells the requester how to get the best results along with a personal note that I have opened the request for them and here's the number for tracking purposes. Say I get a request from a Sales Rep asking why Customer x was charged for Product y.<br />
<br />
<b>I'll send back something like:</b><br />
<br />
<b></b>Mary,<br />
<br />
I have opened request xxxxx for you. You can track it's status here [link to the ticket]. In the future please open a request by going to [some URL] and filling out the request form. This will allow us to assign your request to the best resource and track it to completion.<br />
<br />
Thanks,<br />
<br />
<b>On the next two or three requests from Mary I would send:</b><br />
<br />
<b></b>Mary,<br />
<br />
For best results please open a request by going to [some URL] and filling out the request form. This will allow us to assign your request to the best resource and track it to completion.<br />
<br />
Thanks,<br />
<br />
<b>Finally, I would move to:</b><br />
<br />
<b></b>Mary,<br />
<br />
What's the ticket number?<br />
<br />
Thanks,<br />
<br />
This is not really a science and I might also have a lot of phone calls and chat sessions extolling the virtues of the defined system. It does work over time.<br />
<br />
That's one half of the battle - the other half is getting your staff on board. It going to feel like they are being unhelpful and wasting time because it's easier, quicker, and all around better to just dispatch the request then and there. <br />
<br />
They're right of course for the ones they know about - the problem is the ones they don't notice and come back to you two weeks later as a "your whole team sucks" escalation. <br />
<br />
I expend a lot of effort in the beginning trying to see what people are working on and how it came to them. When I see somebody working on a proper request, I praise them. When I see somebody working from a non-sanctioned request, I reiterate the need for using the defined inputs, and make them put the request in process. It's a huge pain in the ass for both of us, but I know it will pay off quicker than expected.<br />
<br />
A few words about ticketing systems. Once you have a request in process it's fine to do some out-of-band communication to move the request along. IM the requester for a clarification, pick up the phone, host a conference call. Whatever works to help get the job done. What you should definitely not do or tolerate is the deal where your customer puts in a request and then your team updates the request with something like "Need more information" and does not reach out to the requester. <br />
<br />
Most people do not live in the ticketing system and will not continue to check status. They will check on the day of the deadline and be pissed off that the work is not done - leading to a well deserved "your whole team sucks" escalation.<br />
<br />
Defining, Limiting, and Enforcing your inputs will go a long way toward helping you meet the organizations expectations for your team. It takes work, time, and discipline but the payoff is a smoother flow of work and many fewer complaints.<br />
<br />
Thanks for Reading - MikeMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com3tag:blogger.com,1999:blog-6845215548869960100.post-12983374673094675352010-12-31T20:29:00.002-06:002011-01-02T03:10:18.774-06:00Turnaround Toolbox - Learning the Current Expectations<a href="http://www.aperfectworld.org/clipart/metaphors/jumpingthruhoops.gif" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="165" src="http://www.aperfectworld.org/clipart/metaphors/jumpingthruhoops.gif" width="200" /></a>There is a set of expectations for every team. You would hope they would be well defined, reasonable, and achievable. You would hope that existing systems, processes, reports and documentation would support the team in fulfilling those expectations.<br />
<br />
Of course, if that was the case there would be nothing for me to do.<br />
<br />
You have to figure out - as quickly as possible - what the organization expects of your team. This is hard because different people will have different ideas of your mission, responsibilities, and capabilities. Other teams or executives may use the time of transition to add scope - team members may try to reduce scope. It's your job to figure out what the team can and should be responsible for. Pay particular and immediate attention to any SLAs.<br />
<br />
<b>Meet with your team</b> - inventory the tasks, deliverables, reports, and documentation. Don't be surprised to find this stuff scattered around, non-existent, or not forthcoming. The longer the team has been in existence and working together the harder it will be to get even simple things like a complete list of tasks and deliverables. <br />
<br />
You're going to have to dig in and sit with people to see what they are really doing. You will often find that the person doing some ten-step procedure to overcome a common issue does not even recognize it as a task - it's just something you have to do... Same for deliverables; people might produce and distribute needed work product without recognizing it as a required deliverable. <br />
<br />
Figuring out everything that your team does takes a lot longer than you might expect - keep looking, send people on vacation, question everything that seems like it should be on the list but isn't. Why is Joe Blow asking for that from us?<br />
<br />
<b>Meet with your boss(es)</b> - try to understand their idea of your mission. Get copies of any deliverables they routinely receive from your team. Talk about success criteria - expect this to be something very helpful like "be perfect", "100 percent error free", or "Make sure nobody escalates to me." If you're very lucky you will get some objective criteria that is both within your control and something you can measure.<br />
<br />
Something to be on guard for is bogus reporting from your predecessor and areas where the picture has been presented very carefully, giving the impression of more capability than really exists. This stuff can make your job a lot harder, and your life miserable when it takes you by surprise. I have taken over an area only to be asked for a recurring report that nobody on the team has any idea how to produce - and has shown improvement. Upon further investigation all I could determine was that the guy was making up the numbers. Worse, the numbers he was reporting on would not measure the team's effectiveness.<br />
<br />
<b>Meet with your customers</b> - anybody that expects your team to produce work product, perform tasks, etc. is your customer. Find out what they think your team does and make sure you capture any sort of report or other deliverable. As you develop the relationship your customers will become your allies - but you have to make sure you know what they need, why they need it, and what they do with it. <br />
<br />
Almost assuredly your team, bosses, and customers are on different pages or even reading different books. All the work in the world won't lead to success if what you deliver is not what they expect.<br />
<br />
Thanks for reading - MikeMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com2tag:blogger.com,1999:blog-6845215548869960100.post-7194997682868084912010-12-31T13:09:00.002-06:002011-01-04T06:53:35.064-06:00Turnaround Toolbox - Introduction<div class="separator" style="clear: both; text-align: center;"><a href="http://www.aperfectworld.org/clipart/Metaphors/mechanic.gif" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="156" src="http://www.aperfectworld.org/clipart/Metaphors/mechanic.gif" width="200" /></a></div>It's been a long time since I wrote anything - I have been up to my neck in work for the last 20 months. It seems like a good time to capture some old, new, and re-learned lessons.<br />
<br />
As a generalist in the IT world, it is sometimes difficult to tell people exactly what you do. Specialization might make the details incomprehensible, but if you say "I am an Oracle DBA" that's a box people understand. I usually just tell people "I do computer stuff" which is a lot like saying "I am purple."<br />
<br />
What I really do is use decades of broad IT, Business, and Personal experience to help teams perform at a very high level. I plan to write a series of short articles detailing the approaches I have found useful.<br />
<br />
Please feel free to comment, question, or argue with me. <br />
<br />
Here's the list of topics - maybe not in the order I will write them - most of these have to happen in parallel and through many iterations.<br />
<br />
<br />
<ul><li><a href="http://mikeonitstuff.blogspot.com/2010/12/turnaround-toolbox-learning-current_31.html">Learn the Current Expectations</a></li>
<li>Identify and understand the existing Gaps between Expectations and results</li>
<li>Find out what Metrics matter</li>
<li>Start Measuring - Know your numbers</li>
<li>Create your Box</li>
<li>Reset Expectations - internal and external</li>
<li>Develop and Articulate your vision of a better future</li>
<li>Take actions that do not require permission, cooperation, or coordination</li>
<li><a href="http://mikeonitstuff.blogspot.com/2011/01/turnaround-toolbox-define-limit-and.html">Define, Limit, and Enforce you inputs</a></li>
<li>Reach beyond your borders to partner with others</li>
</ul><div>Follow along if you like - I'll try to exert some discipline and write one topic a week.</div><div><br />
</div><div>Thanks for Reading - Mike</div><div><br />
</div>Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-77360655077476375942009-03-27T15:24:00.002-05:002011-01-02T03:15:24.599-06:00Be a Go Getter<a href="http://www.aperfectworld.org/clipart/Metaphors/star_reach.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="http://www.aperfectworld.org/clipart/Metaphors/star_reach.png" width="107" /></a>One of the biggest barriers to advancement for a lot of smart, hard working people is the "Does not show initiative" knock or some variation on the same theme. You would not believe how many times I've been in discussions about who's ready for a promotion and heard something like "Joe does a great job at whatever I tell him to do, but only what I tell him to do" this is the kiss of death because we don't want to tell everybody what to do.<br />
<div><br />
</div><div>This might be a great surprise to many because from the trenches we feel micromanaged and thwarted in our attempts to make the great improvements we know we could make if only we were allowed. It's a conundrum - I admit it.</div><div><br />
</div><div>How do you show you're a "Go Getter" ready for advancement while being micromanaged and thwarted by evil Pointy Haired Bosses that cannot code their way out of an open grocery bag - such as myself.</div><div><br />
</div><div>Well it's simple really. Do the small stuff for yourself or for the PHB of your choice. For instance if I say "let me get with Don and get back to you with an answer" you say "I can check with Don and make sure I have everything I need." This is the perfect response because it takes a task off my plate, and it allows you to get the work done more quickly - not waiting for me or annoying me with constant badgering about did I get with Don yet. Btw the badgering thing will just makes you look like a high maintenance pain in the ass. I do not want to be reminded of my status as a bottleneck... </div><div><br />
</div><div>The scenario above is just the starting point of an upward spiral of Go Getter goodness. Now you are the focal point for the task with Don too - he's likely to be just another PHB and might say "Let me get with Tim and I'll get back to you" For the life of me I do not understand why middle managers so often turn themselves into Gofors. Anyway, same thing, tell Don you can get with Tim directly and that you'll keep Don in the loop if he wants.</div><div><br />
</div><div>So at this point you've helped two managers without doing any more work than you would already be doing. You've made life better for you and Tim because you guys don't have to wait for PHBs to communicate. And you've made it much easier to iterate through possible solutions with Tim - if that's applicable.</div><div><br />
</div><div>Make this little technique a habit and you'll get more interesting assignments, managers will start to listen to your ideas because they'll know that you are not just thinking of stuff for them to do, and when it comes time to select somebody for promotion you are way more likely be on the list. Get on the list often enough and you'll get the nod.</div><div><br />
</div><div>Thanks for reading - Mike</div>Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com1tag:blogger.com,1999:blog-6845215548869960100.post-35406920711618662252009-03-14T06:24:00.001-05:002011-01-02T03:17:32.232-06:00A dozen things Deployment Scripts must do<a href="http://www.aperfectworld.org/clipart/Metaphors/checklist.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="http://www.aperfectworld.org/clipart/Metaphors/checklist.png" width="119" /></a><span class="Apple-style-span" style="font-size: medium;">Just like the barefoot kids of the local cobbler I find the installation of many software packages ironic and painful. Lately I've been talking, a lot, to development managers about getting their deployments scripted and to business people about why Fast, Easy, Reliable deployments are important to them.</span><br />
<div><span class="Apple-style-span" style="font-size: medium;"><br />
</span></div><div><span class="Apple-style-span" style="font-size: medium;">Strangely, there seems to be a real lack of understanding on the part of developers about what a build script should do. I blame <span class="blsp-spelling-error" id="SPELLING_ERROR_0">IDEs</span> for allowing developers to mostly ignore how things get built and deployed - but I could be wrong.</span></div><div><span class="Apple-style-span" style="font-size: medium;"><br />
</span></div><div><span class="Apple-style-span" style="font-size: medium;">Anyway, I've written a list of generic requirements for an automated deployment and this seems to have helped several folks focus their efforts so I thought I would share. I have gotten some feedback that this list is 'pie in the sky' but I reject that while allowing that some of these things are not all that easy.<span class="Apple-style-span" style="font-family: Calibri;"></span></span></div><div><br />
</div><div>An automated deployment should:</div><div><br />
</div><div><ol><li><span class="Apple-tab-span" style="white-space: pre;"> </span>Start with a single package.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Reliably put the target environment into a known state.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Ensure that required disk space is available.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Save anything needed for rollback.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Place all files where they belong.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Register anything that needs to be registered.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Configure anything that needs to be configured.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Start everything that needs to be started.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Validate the state of the application.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Validate connectivity to all required resources such as databases.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Report Success or failure and the name of the artifact you have deployed.<br />
</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>Log all relevant deployment activities.<br />
</li>
</ol></div><div><br />
</div><div>Starting with a single package is important because it's a lot easier and less error prone to move one jar file than a jar file, <span class="blsp-spelling-error" id="SPELLING_ERROR_1">a couple</span> of properties files, a <span class="blsp-spelling-error" id="SPELLING_ERROR_2">config</span>.<span class="blsp-spelling-error" id="SPELLING_ERROR_3">xml</span> etc. Plus you can give the package a name and store it someplace for later.</div><div><br />
</div><div>By "Reliably put the target environment in a known state" I mean just that. If you need to shut down an application server you should also search for and kill any hung processes. If there are status flags, set them to the correct value; basically clean the kitchen before you start cooking.</div><div><br />
</div><div>Nobody wants to get part way through a deployment just to run out of disk. Check it first. This is a no-<span class="blsp-spelling-error" id="SPELLING_ERROR_4">brainer</span>, but often overlooked.</div><div><br />
</div><div>Save your old stuff so you can drop back and punt if needed. I would urge you to save it into a single package just like the one you're deploying. I don't think you should rely on going back to the old package as there may be required changes in the current environment. Those changes should have been the result of a proper deployment, but stuff happens...</div><div><br />
</div><div>Place your files. I usually call this sprinkling - the deal is that your script needs to put every file where it belongs, using an appropriate path reference. If it is always going to be the same in relation to the root directory, I like fully qualified path names. Otherwise I like paths names relative to the installation directory - <span class="blsp-spelling-error" id="SPELLING_ERROR_5">hopefully all</span> within the installation directory.</div><div><br />
</div><div>Register things that are registered. I don't know what you might be registering, but get it done here. Also, start from scratch each time. If you rely on something already being there, at some point it won't be, so trust nothing. </div><div><br />
</div><div>Configure things that need to be configured - whatever they are - same as above, start from scratch. Rather than sending a deltas for a <span class="blsp-spelling-error" id="SPELLING_ERROR_6">config</span>.<span class="blsp-spelling-error" id="SPELLING_ERROR_7">xml</span> send the whole (version controlled) file with the contents you want.</div><div><br />
</div><div>Start everything up. Do this in the <span class="blsp-spelling-corrected" id="SPELLING_ERROR_8">script</span> rather than expecting the guy doing the deployment to do it manually. There's no telling how many hours of otherwise useful human activity have been squandered on troubleshooting just to find that something did not get started when it should have.</div><div><br />
</div><div>Having started everything, go look to see that it is really running. Seems simple because it is.</div><div><br />
</div><div>Validate connectivity. If you need it for production make sure you can talk to it and that it answers. This does not have to be complex, a simple select statement, ping or whatever makes sense for the end point you need.</div><div><br />
</div><div>When something is completed, say so, when something fails, make some noise. Let the <span class="blsp-spelling-error" id="SPELLING_ERROR_9">poor</span> guy doing this in the middle of the night know what's going on. Also, reiterate what version has just been deployed; I have seen people go through a long deployment and troubleshooting session just to find that they deployed the stuff from the previous release.</div><div><br />
</div><div>Build a log as you go. Tell me when each thing starts and stops and what you did. Do not dump a bunch of useless noise in the log though. It should read like a detective's notebook. </div><div><ul><li>22:17 Copied Blahblah1.2.jar to...<br />
</li>
<li>22:20 Change directory to /user/loc...</li>
<li>22:20 Executed jar - xf...</li>
</ul></div><div><br />
</div><div>Above all put yourself in the shoes of somebody that has to deploy your app along with 20 others, in the middle of the night, while taking calls from people that want status, and trying to grab a bite to eat.</div><div><br />
</div><div>Thanks for reading - Mike</div><div><span class="Apple-style-span" style="font-family: Calibri;"><br />
</span></div><div><span class="Apple-style-span" style="font-family: Calibri;"><br />
</span></div>Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com4tag:blogger.com,1999:blog-6845215548869960100.post-26502024509498807052009-01-20T21:45:00.000-06:002009-01-20T22:23:55.539-06:00Has Google lost the cool?<div>I really like my Google stuff. Blogger, Gmail, Groups, Picasa, Maps etc. etc. etc. <br /></div><div><br /></div><div>So why on earth would I be concerned about Google losing the cool factor? Well at home I run <span class="blsp-spelling-error" id="SPELLING_ERROR_0">Ubuntu</span> - the first little warning for me was that <span class="blsp-spelling-corrected" id="SPELLING_ERROR_1">Picasa</span> on Linux is a wine app. It offended my sensibilities some, but they had at least made a good installer and it was easy for me - I don't remember the details but it's on my desktop and works so it must have been easy, or I would have pissed and moaned back then. </div><div><br /></div><div>They have kinda pissed me off with Chrome. I mean sure it renders quick and has the cool, visual thing about where I go, I can just click the x for a new tab, and the interface is super clean. But Google provides no help with a Linux or <span class="blsp-spelling-error" id="SPELLING_ERROR_2">OSX</span> version. I went to the trouble of installing Crossover Chromium - a good effort but even CodeWeavers knows it not very good. So now, like some street corner crack dealer, Google has given me a taste of the new browser drug and ruined me for <span class="blsp-spelling-error" id="SPELLING_ERROR_5">Firefox</span> - but I gotta run windows?</div><div><br /></div><div>For most companies I would not care, but Google started off so cool and they've hired all sorts of smart OSS guys that are presumably Linux and Mac users. Why then are new Google applications targeted so relentlessly at Windows? I know that's an overstatement but only by a bit. Is it really so hard to make the cool stuff cross platform? Do the non-windows users of the world really mean so little to Google that they don't even bother to give us a semi-elegant hack anymore?</div><div><br /></div><div>Has Google already gone lame and big business on us? Do Guido, Stevie, and so many others need to look for the next cool place to work - are they even vested yet? I hope I get some spam from Google before the end of the week saying all their stuff is available for <span class="blsp-spelling-error" id="SPELLING_ERROR_6">OSX</span>, Linux (in Deb and RPM) as well as windows. They could even blow a little smoke up my skirt about how cool they still are. While they're at it maybe they could update the spell checker in Blogger.</div><div><br /></div><div>Thanks for reading my rant - Mike</div><div><br /></div>Mike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com2tag:blogger.com,1999:blog-6845215548869960100.post-65324879602731933282008-10-11T13:12:00.000-05:002008-10-14T14:08:26.011-05:00Movin' on upIt's late September and I really should be back at school - but that was nearly thirty years back for me and the boat has sailed. So late September or early October just means review time for me and the folks that I keep amused.<br /><br />Top questions this quarter;<br /><br />How do I move up?<br />When do I get a promotion?<br />Do I get a raise for attaining this certificate, degree, tenure?<br /><br />It's got me thinking a lot about who moves up, who doesn't, and why. Or at least I'm thinking about who I want to help and who I don't care so much about helping. So here are some attributes in no particular order:<br /><br />Focus more on making my life better. I don't mean kiss my ass or pick up my cleaning. I mean get better at your job so I can deliver good news in meetings with my boss.<br /><br />Focus more on making your teammates lives better. Come up with, and share, better ways of accomplishing the mission. Cross train in their job so you can back them up when needed. Smile instead of frown. Acknowledge their value to the team and help them get better too. Give credit whenever you can - it makes you look better and builds trust.<br /><br />Focus on making our customers happy and comfortable. Our customer is anybody we deal with outside the team - even the folks who service our requests. Be polite, humble, and easy to deal with even when the customer is wrong or is acting like an ass. I'll step in during those occasions and get things straightened out for you.<br /><br />Get passionate about what you do, or find out what already turns you on and do more of that. Nothing is more frustrating to me than a smart person who just does what I tell them to do. I don't have the time, or inclination to tell you everything - show some initiative. If what you want to do is in a different area of the company I'll help you get there, if I believe your story. It's better though if you're excited about the job you have and want to make improvements there.<br /><br />Think big and persevere. It can be frustrating because organizations resist change with more vigor than they do anything else; think big anyway and keep pushing forward a fraction of a step at a time toward those goals; it always takes longer than we want and still happens faster than we realized if we just keep moving.<br /><br />Do the above and quit worrying about your career progression so much. The people that do this stuff have me working on their career even if they don't know it.<br /><br />Thanks for reading - MikeMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com4tag:blogger.com,1999:blog-6845215548869960100.post-7305715671588727652008-09-25T19:55:00.000-05:002008-09-27T15:24:17.018-05:00Why Masters MatterSo I've been getting beat up a bit on the extremeprogramming mailing list. Part of the issue is that I often don't know what the hell I'm talking about; even when I do I don't express it as well as I should.<br /><br />I post questions or statements about what I want to try, and I get back responses that I'm trying the wrong thing or going about it in the wrong way. And that what I need is to hire a coach, get some assessment, and have some more conversations.<br /><br />I have to admit it was getting on my nerves. I can read, the practices are not super complex - what the hell?<br /><br />Anyway, on the theory that if a lot of people that have been in the field are saying the same thing and seem to agree with each other, I should listen, I called <a href="http://en.wikipedia.org/wiki/Ron_Jeffries">Ron Jeffries</a> to talk for a bit this morning. We talked about some of the things I had posted and some other stuff but rather than getting any kind of prescription I got nuggets of wisdom - some of which have been percolating all day.<br /><br />As an example I had the idea that I should require a set of XP practices and provide training in those practices. On the list I got a lot of feedback that requiring practices is a horrible idea. I was confused by this - I'm talking about having people do the stuff you guys say work and I'm getting a bunch of noise back - again, what the hell? Am I supposed to just hope that people will do the right thing? Who's gonna feed my kids when I get fired?<br /><br />Ron cleared the whole thing up for me in like one paragraph of talking. I'm paraphrasing here but he essentially said that I could require running software that passes my tests. In other writings he calls that <a href="http://www.xprogramming.com/xpmag/jatRtsMetric.htm">Running Tested Features</a> (RTF.) Anyway, having a requirement for RTF, developers might look for easier ways to satisfy the requirement and the proverbial we could suggest practices and provide training/coaching.<br /><br />Ding Ding Ding - that makes perfect sense to me. It clears up many of the responses I got on the list, and it completely illustrates why I should indeed sit at the feet of the masters. I could perfect every practice and make people do them, but still not get the RTF I need.<br /><br />So now I'm going back to see about shaking budget loose to bring Ron and Chet in for a few days of master wisdom - wish me luck<br /><br />Thanks for reading - MikeMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com1tag:blogger.com,1999:blog-6845215548869960100.post-91792707893174983892008-09-20T09:31:00.000-05:002008-09-28T19:07:42.204-05:00Story size - and Motorcycle ridesI ride bikes in three distinct landscapes, and where I'm riding has a lot to do with how I approach the activity.<br /><br />On a road race track I know the profile of every corner, the available traction, and all the landmarks. I can fully commit to my line and string the curves together so that the exit from one corner sets me up for the entrance to the next. I'm going to see the same sets of corners every minute or two, I know exactly what I'm going to do well in advance, and I can think in big chunks of track - I have to do this to be fast. I can clearly see where I am going and plan every action along the way before I even get on the bike. Then it's just a matter of improving my execution through practice and repetition.<br /><br />A semi-equivalent software development system is making cookie cutter websites with branding. The customer just chooses from a menu of re-usable functionality and most of the discussion revolves around the branding elements. The analogy with track riding breaks down though because riding a motorcycle at speed around a race track is just a bit more engaging then churning out cookie cutter websites.<br /><br />Street riding - even on a familiar route is a whole different game. There are cars doing all sorts of seemingly random stuff, gravel on the road that was clean yesterday, driveways, pedestrians, and who knows what else. On the street it makes no sense to commit all your traction to a corner, or to be too attached to the exact path of travel too far in advance. You want to look a far ahead as possible, watching for the telltale signs of trouble so you can adapt your approach to the changing conditions.<br /><br />This is the sort of environment that most corporate software development takes place in. There are regulatory changes, market conditions, new internal customers with their own ideas for improving things, and always budget constraints. The rules are very similar to riding in traffic. You know where you want to end up and you know pretty much what route to take but you must be ready to adapt to the changing conditions.<br /><br />Finally there is off road riding. This is incredibly interesting and challenging. Often I don't know where the next bit of trail is going, or what the surface will be like. I can only plan very short intervals of the future and even those plans are subject to change with very little notice when the trail takes an unexpected turn ,or traction disappears in the middle of a challenging hill. I fall down a lot when riding offroad.<br /><br />New product development is a lot like riding off road - you're always inventing something new and there's no telling where you might be even in the near future. It's also very interesting, a lot of fun, and you might fall down from time to time.<br /><br />It is exceedingly rare that I fall down on the track or the street and falling in either of those circumstances can be very expensive in financial and human terms because the typical track or street bike is very sophisticated and street bikes in particular are heavy. Off road I fall frequently, and really appreciate the light weight, easy maneuverability, and durability of my dual sport bike. It turns out that the lightweight and simplicity of the dual sport are great on the track and street too.<br /><br />Agility makes riding on the track more pleasant by requiring less effort to execute my plan, it makes street riding safer by making it almost effortless to adjust to the changes I see ahead, and it's a whole lot easier to pick up when I fall offroad. Similarly, I think agile processes make life more pleasant, safer, and resilient in any area of software development too.<br /><br />Thanks for reading - MikeMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com0tag:blogger.com,1999:blog-6845215548869960100.post-69483458350516401872008-09-19T12:25:00.000-05:002008-09-19T13:20:47.731-05:00A little slow on the uptakeSometimes we just want to invent stuff for ourselves. We often pay lip service to the idea of learning from the mistakes of others and profiting from lessons learned and work in the can; we might even believe it. But still we do our own thing, make our own mistakes and come to many of the same conclusions of those that have come before.<br /><br />Over the last few weeks it has really come home to me how much I tend to think I am at least as smart as all those other guys, and that I can surely figure things out for myself. I still think it's true, but why would anybody want to live without delusions - especially delusions of grandeur?<br /><br />Earlier in the year I wrote some articles on agile development and how great I think it is to be agile, with some examples of how things might be done. You can find them on my <a href="http://mikeonitstuff.com">old blog</a> if you care to. <br /><br />The thing is though, I almost completely ignored extreme programming(XP) and Scrum. <br /><br />XP because when <a href="http://en.wikipedia.org/wiki/Kent_Beck">Kent Beck's</a> book first came out, the whole process just seemed kind of flaky and inappropriate for the kind of large organizations I was working in. I could see myself talking to an auditor and handing over stacks of 3x5 cards when asked for system requirements - as if. I was also somewhat turned off by the idea of pair programming - I do not want to sit shoulder to shoulder with anybody all day, not having to is one of the perks of IT work. <br /><br />Scum because the name is asthetically unattractive, and at first glance it looks like a ripoff of XP without the good engineering practices. What's the point of that?<br /><br />I was stupid. I should have been paying better attention because over the years while I've been thinking about process improvement, reducing the signal to noise ratio of system docs, and removing friction from people's lives; these guys have too. And they've been doing it in all sorts of settings as consultants and coaches. XP has matured, lessons have been learned, and practices have been improved. They've even done some studies showing gains from pair programming and TDD. It also turns out that Scrum is more than just a subset of XP - though the name still leaves a lot on the table of asthetics if you ask me.<br /><br />A few weeks back I was invited to join a team of folks at work to explore moving to an iterative development process. We had bought a smaller company that had recently adopted Scrum and did not/does not want to go back. That gave me an opportunity to really look at Scrum which quickly led me to revisit XP as well. <br /><br />I have been in a total immersion self study course - reading the websites, comparing the variations, joining the mailing lists to ask questions, and watching a bunch of video presentations on <a href="http://infoq.com">infoQ</a> from many of the guys that started XP and Scrum. It turns out that I agree with almost everything with the possible exception of the sales pitch that includes things like 'add joy to the workplace.' <br /><br />Not that I'm against <a href="http://mikeonitstuff.com/2007/03/21/create-an-great-place-to-work.aspx">creating a great place to work</a>; but even I - raised mostly in the west by hippies - can see that the guys writing the checks are not all that concerned, even if they should be. I would rather see a sales pitch that talks about ROI and behaviors that lead to greater ROI in the long term. We all know that happy porogrammers will be productive so let's just talk about the corporate behaviors that lead to happy programmers in terms of the benefit to the bottom line, and leave the happiness argument out of it.<br /><br />If, like me, you've been kinda ignoring XP and Scrum as something nice for small teams of folks that won't eat a good bar-b-que sandwich with a side of slaw; reconsider. Get out there and watch the videos, read the websites, subscribe to the mailing lists, and ask a lot of questions. I don't think we can tweak the old waterfall (dinosaur) method enough to survive the onslaught of the furry little XP critters.<br /><br />Thanks for reading - MikeMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com1tag:blogger.com,1999:blog-6845215548869960100.post-31582148815609260352008-09-09T17:33:00.000-05:002008-09-19T13:24:38.340-05:00Reset the blogSo I wanted to move to blogger for a variety of reasons but moving all my <a href="http://mikeonitstuff.com">old stuff</a> over here turns out to be more work than I'm likely to do. But rather than continue my procrastination on writing I figured I would just tell you what's up and start writing again.<br /><br />There's a lot of interesting - to me at least - stuff rattling around in my head and I'll be letting it run out onto this space much more frequently.<br /><br />Thanks for reading - MikeMike Coonhttp://www.blogger.com/profile/09264497793546775250noreply@blogger.com1