The Agile Executive

Making Agile Work

Posts Tagged ‘Hyperproductivity

Agile Across the Enterprise: Prioritizing Value in Support and Training – Guest Post by Anne Gentle

with 6 comments

If I could choose a subtitle to Anne’s guest post, I would pick How to Produce a Book in Five Days. While this subtitle does not take into account preparatory work prior to the five days, it captures the essence of the revolution in social publishing. The  intensive collaborative authoring that takes place during book sprints leads to hyper-productivity that transforms the economics of various classes of books.

A thread of particular interest in the post is the path innovation took. Anne walks us from Cote‘s simple question “Why does it take three days to get a PDF out for review?” all the way to producing over 250 pages of documentation in a book sprint. Her story is a great proof point that Experimentation Matters.

Here is Anne:

One of the Agile Manifesto’s basic balance equations is valuing working software over comprehensive documentation. This line of the Agile manifesto can be confusing to some supporting roles in an Agile development enterprise. As technical support staff, trainers, and content creators, what are we doing to fit into this Agile methodology, and what’s working well? Let’s explore some old habits that need to die, and some new rituals to fill that space.

Nowadays, Google’s search power offers software users access to documentation through forums, mailing lists, even through blogs and wikis maintained by the developers and authors themselves. These new conversational methods for documentation, support, and education have opened new opportunities for those groups to add value to software adoption. Ways to provide additional value to the working software include helping people learn the software, troubleshoot the software, or do their job with the software. Education, uptake, and support are all integral to the overall value of a software product.

Value proposition

First, a discussion on the value added by good websites, updated and relevant training materials, and a helpful support staff.  Those departments want to avoid the continual cost center perception. To do so, they find ways to add to the bottom line, such as:

  • increasing sales (enterprise) or increasing adoption (open source)
  • keeping users happy and satisfied
  • adding contributors to the community, whether helpful troubleshooters or prolific coders
  • decreasing support costs (in time and money)
  • converting participation into value
  • increasing positive perceptions of the software

In my experience, these values are universal to both enterprise software and open source software. Let me share my story.

Wikis are an Agile tool

I have been a technical writer on Agile development teams, and working in tightly collaborative environments has taught me a lot about adding value in the customer’s perception. I still remember being challenged by Michael Cote when we were at BMC Software. He asked, “Why does it take three days to get a PDF out for review? Why aren’t technical writers using wikis for documentation?” Those questions prompted quite a bit of research that finally resulted in my book, Conversation and Community: The Social Web for Documentation.

I had a lot to learn to answer Cote’s questions. What to do? I decided a wiki apprenticeship was the answer. At the time, wikis seemed to be the realm of open source software. I was nervous about approaching an open source project with so little experience in open source to draw from, but when a former BMC director sent out a call for help with the One Laptop per Child project, I responded. They had a draft started and we put it on the wiki.laptop.org wiki to start with, as a too-long single article on the wiki. Soon after, FLOSS Manuals approached OLPC to see if they would like to have FLOSS Manuals host the wiki on their wiki site at www.flossmanuals.net. Adam Hyde, the founder of FLOSS Manuals, had built a wiki tool that allowed multiple chapters to be output as HTML or PDF. When I saw what the tool could do, I jumped at the chance. We copied and pasted the entire manual into the FLOSS Manuals site. Yes, copy and paste. But it got the content into a platform that enabled much more agility for the content.

Book sprints are one Agile method

After that initial content seeding, we discussed holding a book sprint to create a better book for more audiences, especially since SugarLabs had formed an organization separate from OLPC to work on the operating system separately from the hardware. A book sprint, much like the Agile sprint term, is intensive collaborative authoring in a week’s time. We run sprints as a five-day event, and use real-time collaboration tools, and sometimes bring all the authors in to a single location and have a bullpen of sorts. Lots of planning goes into a book sprint prior to the actual sprint, such as identifying sources of content that can be repurposed for the sprint, agreeing to the audience for the resulting documentation, and writing an outline for the deliverable, whether it’s intended to be a textbook, a curriculum workbook, an online help system, or a website.

After a sprint planning session on the Sunday of the sprint week, authors are ready to start writing immediately because the outline for the book is set in the wiki. Often we outline with Post-it notes on the wall to start, a familiar sight to many Agile practitioners.

Monday, Tuesday, and Wednesday are heads-down writing days from about nine in the morning until an enforced stop time at six each day. Just like a stand-up meeting, we use a daily conference call to stay in touch with the handful of remote contributors and find out if anyone is stuck or has questions. Thursday is a day for assessing how much we have so far, and what final tasks should be done to make the sprint a success. Thursday night we intentionally plan for a fun event, as the writers certainly have experienced an intense effort like no other and need to have some fun and allow for a release of built-up pressure! Friday is a clean-up and review day, and the final PDF is uploaded to Lulu.com for creating a bound book. We can also export the wiki content to HTML, and either embed it on a website or ship it with the software product itself. In the book sprint for OLPC and SugarLabs, we produced over 250 pages of documentation. You can learn more about book sprints (including examples of the budget for this sprint) by reading the free chapter from my book, or by reading the book about Book Sprints hosted on FLOSS Manuals.

In my journey towards Agile value-add across the enterprise, I learned that wikis are much more likely to be used internally for collaboration, and that there are far fewer examples of wikis where customers and Agile team members are collaborating on training materials, tutorials, reference information, or strategy guides for enterprise software. To shift that adoption rate towards external collaboration, I’m interested in book sprint experiments in the enterprise, as well as additional collaboration methods. Along the way, I’m finding ways to transfer lessons learned in open source to corporate environments. I offer this story as one way that Agile methods applied to other departments and their processes can increase overall value to the software developed.

About the author: Anne Gentle works as a senior technical writer at Advanced Solutions International in Austin, Texas on an Agile development team. She just finished a book with XML Press about using social publishing techniques for technical documentation titled Conversation and Community: The Social Web for Documentation. She volunteers as a documentation maintainer for FLOSS Manuals, working on manuals for One Laptop Per Child and SugarLabs, both education projects dedicated to providing technology for children in developing countries. She writes a blog at justwriteclick.com and welcomes feedback and conversation there. As the mom of two young boys, she loves to be busy while upholding the value of an Agile principle of individuals and interactions (and sometimes refereeing battles over toys).

Advertisements

“How do we move towards an agile procurement or agile development methodology?”

leave a comment »

Colleague and friend Annie Shum sent me the following excerpt from  U.S. CIO Vivek Kundra’s Friday keynote talk at the University of Maryland’s CIO Forum:

Questioned on whether service-oriented architecture still is an emphasis in a federal cloud computing paradigm, Kundra said SOA “absolutely” still matters. “Look at the Social Security Administration and what it’s done with SOA and local government,” he said. “They can build lightweight applications to interact with databases elsewhere.” That embrace of modern development practices extends beyond just SOA or upgrading programmers’ skills from COBOL. “How do we move towards an agile procurement or agile development methodology?” asked Kundra [highlighted by IG].

The {SOA –> agile procurement –> agile development} connection is intriguing. Obviously, Kundra gets the nature of the next revolution in productivity. My hunch would be that Business Service Management, particularly in its Agile BSM flavor, would soon be added to the mix.

10 Steps for Setting up an Agile Start-up

with 4 comments

Mapping the Agile thinking, theory and practices to the realities of the target company is a tricky part of making Agile happen in a sustainable manner. HubOne’s Nick Beaugeard, known to readers of this blog from his post Enterprise Product: $50,000 and 8 months – You Must be Kidding, shares with us his recipe for so doing in a start-up environment. He manages to weave the pragmatic details with the core principles behind software development in general and Agile methods in particular. For example, consider the following insight provided by Nick:

In fact, when developing an API, the unit tests are your clients!

Readers of this blog might want to compare and contrast the thoughts Nick expresses in this post with those of:

  1. Ryan Martens on prescriptive versus adaptive rollout of Agile (click here).
  2. Eric Ries on iterating on the problem definition and developing the customer base in parallel with iterating on the solution (Click here).

Here is Nick:

After my last post, where I discussed the concept of implementing the tools and process before you get people on board, I though it appropriate to provide some prescriptive guidance on how we achieved the process. This post is primarily aimed at start-ups where you have total control over your infrastructure, computers, network and internet connection. If there is enough interest, I’ll produce another post of how to perform the same, but in a corporate environment.

I believe, and my experience has shown, that preparing your work environment, tools and process before the team starts coding helps eliminate costly and lengthy discussions about tools and process. In fact, in my experience, most developers are pleasantly surprised to find the environment ready and working and slip into the processes extremely quickly.

So, please find below my ten steps. Following this process really helped us get up and running quickly. Whilst we used Microsoft Development tools, this equally applies to their open source equivalents, so feel free to substitute specific tools, just not the requirements and process.

  1. Authentication, Network and VPN. Setting up the core of your environment is critical. As you are more than likely working on secret software at the outset, you need good, auditable mechanisms for authentication and logon. In addition, we don’t want our developers to have to do anything except start their PC or laptop and login, and we really want them to be able to work remotely. If you don’t feel qualified or able to complete the steps below, any good local IT Pro should be able to set this all up for you. To perform this, we implemented the following:
    1. Network Connection – we are in Australia so our networks are not fantastic. We subscribed to a good ADSL 2+ plan (24Mb) with a 80Gb limit. We implemented a modern ADSLwireless modem/router and configured it correctly. This gave us acceptable internet connectivity.
    2. Domain – We implemented a domain controller running on Windows Server 2008. This gave us corporate authentication, auditing and identification. The domain controller was hosted on our private network (see 1.c)
    3. Routing and VPN –our internal development network needed to be protected from internet connectivity so we implemented a Windows Server 2008 machine with two network cards (called multihomed). One card was connected to the router and one connected to an Ethernet switch. We used a private IP subnetfor our development Local Area Network (LAN) and enabled Microsoft Routing and Remote Access. This gave us the ability to authenticate domain users to VPN into the private network for remote working. We then configured our router to allow access to the server for VPN Access.
    4. DNS –one of the issues you face with ADSL is that your Internet IP Address changes often. The solution for this was to use a solution from DYNDNS (www.dyndns.com) which allowed us to register a host name, coupled with a client application which ensured our host name for VPN always pointed at the correct IP Address.
    5. DHCP –it’s a real pain, especially when using VPN when your client machines are configured for static IP addresses. We used Microsoft Dynamic Host Configuration Protocol (DHCP) to ensure every machine had a unique IP Address and that our networking became just “plug-and-play”
  2. Version Control and issue tracking – in my experience, there are four critical systems needed for any software development team. These are:
    1. Version Control – Also known as source repositories, these systems allow control over check-in, check-out and versioning of source files. I cannot recall the number of times we backed out an individual source file to a previous “working version”. Without this in place, I can guarantee you’re going to struggle maintaining a good code base!
    2. Bill of Materials– the way I use these is to highlight each of the key deliverables in a project. When building Enterprise Profile Management, our BOM had 345 separate items, everything from the corporate website, to graphic design, to core components of the API. The Bill of materials is a way to track the overall progress of the project. Each item in the Bill of Materials should have at a minimum a title, description, owner, due date, % complete and %tested. We also use the bill of materials to determine our release criteria (more on this later).
    3. Build System – the biggest mistake a development manager can make is to not build the software regularly. We build our software system every time there is a new check-in (called continuous integration). Even with a very small team, the ripple effect of changes could go un-noticed for ages without building regularly. As an aside, we also have a Nabaztag (www.nabaztag.com) bunny which tells us whenever there is a build, whose check-in caused it and whether it succeeded or failed. While this is really annoying, it focuses the developers on good check-ins. We might also make the person who broke the builds buy us a round of beer, but that’s a secret!
    4. Issue Management – More important than email, IM, or indeed any other form of communication in the development team is issue management. I believe that in  a project of any size, you’ll be hard pressed to ever finish if you don’t have good issue management. Issues should contain a title, description, history, assignee, status and indicate which version/iteration of which product the issue applies to. I don’t actually think a spreadsheet will cut it here. If there’s one investment you make, make sure it’s issue management.
      We used Microsoft Visual Studio Team System for all of the above. Being an ex-microsoft product team member, I am familiar with the way the product works, but there are lots of plug-ins available for scrum, agile (MSF) and CMMI. To do this on a startup budget, we were able to join the Microsoft BizSpark program (http://www.bizspark.com) which gave us instant access to Microsoft’s developer tools. I’d highly recommend taking a look at that program!
  3. Backup – Now is the time to do a backup and recovery operation. You have no real data in the system and how you installed it all is probably fresh in your mind. Trust me, every first recovery operation fails. You need to imagine your office has been hit by lightning and you have no servers, and just a backup. If you can successfully recover your environment in under 24 hours, you’re in a good place. Document how to do it and test it regularly.
    When we were developing Enterprise Profile Management, our server with all issue management, reporting, builds and version control failed (the processor fried). We were taking backups, but the restore failed. It took me 22 hours to perform a forensic recovery of our production platform. Luckily the developers could work offline, but we still introduced a ton of integration bugs. Don’t skimp on backup.
  4. Email, IM and Web Conferencing – You’re going to be working remotely at some time, whether you think you will or not. We quickly implemented the following tools:
    1. Email – Google Gmail for your domain (www.google.com/apps)
    2. IM – Windows Live Messenger and Skype (www.live.com, http://www.skype.com)
    3. Web Conferencing – Dim Dim (www.dimdim.com)
      Note: there are lots of other tools out there, we just chose these (with little science, but they’ve worked well for us)
  5. Coding Standards – Getting at least some coding standards in place before you write any code is really important. Good Version Control Systems should be able to validate code against your standards on check-in. My key coding standards are:
    1. No String Literals – All strings must be externalised in resource files for later localization (a process called globalization)
    2. Commenting – I insist that every class, method, property, event and interface be commented. There’s method in my madness here; obviously code commenting is important but with proper commenting (especially in C#) and tools like sandcastle, you can automatically create documentation like ours at http://api.hubone.com.
    3. No Short Cuts – This one was a little contentious – Our code will in the future (hopefully) be worked on by people who had no idea of the concept. Writing out If…then constructs and property accessors in long-hand makes the code much more readable for novices, junior programmers, support teams and architects alike.
    4. Unit Test Everything –I insist that every method, property, event etc, etc has an associated unit test. These we execute as a part of the build. My goal is to have over 80% of any code written covered by unit tests. In fact, when developing an API, the unit tests are your client! Although this increases the programming effort up front, it actually reduces the total time taken to ship the product. I havelost count of how many times our massive unit test library has saved us from nasty regressions that we could never have found from UI testing.
  6. Write some code –Don’t worry, you don’t need to be the world’s best developer to write some code. All you need to do is think carefully about the different items in the Bill of Materials and start prototyping the methods, properties and events that will make it all work. Ensure you adhere to your coding standards. The goal of this exercise is to effectively build a skeleton of your application before the developers get on board. This can make them hyper productive when they start. They’ll probably end up getting rid of every line of your code, but it will get them in the rhythm of how you want the platform to look. As the architect of our platform, I used this period to prototype and test all of my assumptions of how things would work. By the time the developers got on board, I had a passable working prototype of an API with unit tests and coding standards, although there is almost none of my code in the final product, this enabled us to get running really quickly.
  7. Don’t write a test plan – Write the user documentation instead, and use this to test your application. That way you’ll know your application does everything the user guide says it does and you won’t double up on a test plan and the user guide (which should end up being pretty similar anyway). I wrote our user guide because I knew what I wanted the product to do and it’s also a fantastic way (sometimes they only way) you get to communicate with your customers.
  8. Give ownership, responsibility and praise – You will have no choice. As you get developers, testers, writers and others on board, you must give them ownership of components. I find that if I give someone total ownership, they always deliver. People are proud when they do great work and if they feel and really have ownership over something, it will be their best work. Not only that, but they’ll pull out every stop to impress you, the team and your customers. If you hire correctly, you’ve got great professionals in the team. Respect them as professionals and the results will be awesome.
  9. The best wire framing tools are not wire framing tools – You’re a start-up, right? Then you’ve discussed your ideas with potential customers and you deeply understand their needs. You could sit down with any number of wire framing tools and attempt to design components. How about you take a different approach? Write functional code which does what you (and therefore your customers want) – Developers find it far easier to code from a working model and they can re-use portions of your code. All of this streamlines the process and you can take your models to customers (with caveats on your poor coding skills and lack of stylistic ability).
  10. Constantly review and drive – We spend some time every day in front of a whiteboard discussing options, vision, checklists and almost everything else, but in a start-up, it’s not really a democracy. I run my start-ups like a benevolent dictatorship – I hold the final decision, but let everyone have input. I’m the one talking to customers, and sometimes I bring customers in to explain a requirement, but at the end of the day, how it works is up to me (I have the most to lose if it doesn’t work!)

Notice here, we never had a specification, requirements specification or design, we build the code a piece at a time and made it work. We’ve gone back and documented some core functionality, flowcharts and features, but at the outset, it’s more important to make it work. I’ll share a caveat, though, I’m also the software architect so I can hold the requirements for scalability, security and reliability, and guide the team to accomplish those goals.

Hiring the team can happen sometime between points 7 and 8, I don’t recommend you do it before!

If you’d like more information, please feel free to get in touch at nick@hubone.com, and if you’d like a copy of the software this built, we can be found at http://www.hubone.com.

Timing and Duration of the Agile Roll-out

leave a comment »

A measure frequently considered by executives these days is the introduction of Agile as part of cost reduction initiatives. To succeed in attaining cost benefits through the higher productivity of Agile, the plan for introducing it needs to take into account the slippery slope that repeated cost cutting measures tend to lead to. In particular, the timing of rolling out Agile and the duration of the roll-out need to be carefully considered to avoid a possible cart-before-horse situations.

A cart-before-horse situation is likely to arise as a result of the following pattern:

  1. An executive’s budget is under pressure.
  2. Headcount reduction is carried out. Remaining employees are expected to somehow cope with the load.
  3. Agile, with its promise of higher productivity and possibly hyper-productivity, is introduced as a counter-measure to the reduced headcount.
  4. The remaining development resources are expected to acquire a new set of skills, to master the art of Agile.
  5. The need to acquire Agile skills flies at the teeth of remaining employees needing to regain expertise that was lost by reduction in headcount. In many cases, the remaining development resources are already stretched too thin.
  6. Staring at the choice between acquiring specific domain expertise in a critical area versus developing less concrete expertise in software methods, more often than not the remaining employees and the system around them will opt to concentrate on acquiring domain expertise. For example, if a product fails to satisfy a new security benchmark introduced by key customers, the need to respond to the security benchmark is likely to take precedence over studying estimation techniques for Agile.
  7. Goto #1 above.

To preempt such cart-before-horse situation, the following principles need to be adhered to:

  1. Don’t introduce Agile before “the system” adequately adjusted to a round of headcount reduction.
  2. Do not carry out layoffs during the assimilation phase of Agile. In addition to cart-before-horse situation as described above, headcount reduction could jeopardize two critical pillars of Agile: empowerment and collaboration.
  3. Establish a quantified baseline of productivity before starting an Agile roll-out. Measure Agile progress against the baseline.
  4. Do not bet the Agile roll-out on linear improvement in productivity. A good Agile implementation is likely to improve productivity, but it is quite tricky to predict the shape of the Agile learning curve.

In practical terms, your organization needs to take a strong “medicine” up-front to break the vicious cycle that repeated staff reductions amidst an Agile roll-out are likely to create. The medicine should be strong enough to last through the period of time required for a meaningful assimilation of Agile. A good way to assess how long the period might be is to consider Agile as apprenticeship – one learns by “Agiling” with the masters.

You need to ask yourself the question “Can We Afford the Software We are Developing?” if business circumstances do not allow for reasonable adherence to the principles cited above.

Companies make shoes!

with 2 comments

Peter Drucker made an astute observation which is quite relevant to the current business situation during a September 1998 interview with Fortune:

Securities analysts believe that companies make money. Companies make shoes!

Readers of this blog might have said “software” instead of “shoes.” The point would have been similar to Drucker’s. Good financial management is no doubt  important for your company’s success. It is no substitute, however, to focusing on the business you are in, the technology(ies) that drives the business and the effectiveness of the underlying systems and processes.

The current macro-economic situation gives you an opportunity to soberly assess the viability of your business design (as distinct from doing a lot of financial engineering). With asset inflation corrected, measuring the effectiveness of your business model in terms of the ratio Market Value/Revenues is much more meaningful now then it used to be prior to September 2008. As pointed out by Slywotzky in Value Migration, a market value to revenues ratio lower than 0.8  indicates value outflow for your company and possibly for your industry.

For software companies, the impact of “good enough” Open Source Software should be assessed in conjunction with close examination of the market value to revenues ratio. Twitting from the recent OSBC conference in San Francisco, colleague Andrew Dailey of MGI Research reported “… ERP/CRM are viewed as least susceptible to open source disruption… due to high transaction volumes and high integration needs.” Conversely, Andrew considers office productivity software as ripe [for the picking by Open Source Software]. I am personally of the opinion numerous Application Life-cycle Management tools could be massacred by Open Source Software.

The confluence of the threads highlighted above poses a fairly unique opportunity for the Agilist to convey a major premise of Agile to his/her executives. Like a thriving Open Source Software community, a hyper-productive Agile team can pick a ripe market faster and cheaper than an old fashioned software company could. Moreover, if a company is in one of the markets that are susceptible to an Open Source Software onslaught, Agile can (up to a point) provide defense against such onslaught. Whether you choose to attack or defend, Agile software gives you the advantages of proprietary software at a fraction of the traditional cost.

Five Imperatives for End-to-End Agility

with one comment

David Worthington, Steve Brodie,  Brett Adam and I just finished part I of the End-to-End Agility webinar. The focus of the webinar is on ultra-fast development, test and deployment through:

Slides and recordings from the webinar should be available in 48 hours. Until then, I will just mention the five imperatives identified in this webinar for accomplishing End-to-End Agility:

  • Self service
  • Scalability
  • Collaboration
  • Control
  • Automation

Part II of this webinar series will be delivered in early April. It will emphasize the effects of hyper-productive Agile teams on operations.

Written by israelgat

March 5, 2009 at 3:51 pm