What is “Retired” in the 21st Century?

In 2007, after resigning from Model N (the company that bought my start-up Azerity), I established Duck Pond Software and wrote my first blog, “Retirement or Another Start-Up?” In that blog I wrote “My husband says I’ve “retired”. I don’t know what that means. The beauty of being in software is that as long as you have access to a computer, you can do all of the fun activities you did at your job (but just not get paid for it – humm.)”

Shortly afterwards, Model N asked me to return which I agreed to do as a consultant. It was part-time and in parallel I started blogging and creating websites for various groups including this Duck Pond Software site.

During a lull in Model N work in 2011, Freeman & I formed a partnership and created Software 2020, the 21st century tool to replace our SD Tracker bug tracking tool but expanded to support Agile and more. Then back to work at Model N as business picked up there.

Seven years later I did it again (terminated work with Model N) – not out of frustration with the company direction or technology this time. Before I left I was able to influence some important changes in company direction and to restore the product’s platform to a clean, maintainable architecture.

Feeling like I accomplished what I wanted to do at Model N and looking forward to a free schedule to do what I want to do when, here I am “retired” again. This time another start-up is not something I am looking for. Nearly 20 years of start-up life has been plenty. Nor is my goal being another VP of Engineering at a company I do not own.

I’m not void of work. Since 2009 when I learned about the state’s plans to ruin the Delta where I live in order to send our water south to benefit primarily rich agribusiness corporate owners in the Central Valley in their never-ending expansion to sell almonds to Asia for significant profits, I’ve become somewhat of a water activist, focused on Delta water issues and on stopping the BDCP’s Delta Tunnels. Being President of the non-profit Save the California Delta Alliance (STCDA) takes a lot of my time.

Also there’s boating and golf and travel and grandkids.

Will that be enough?

Probably not. I am a software evangelist. It’s in my blood. With the internet it’s easy to continue the discussions, mentoring of new engineers and managers, and hopefully help improve the current software methodology.

At Azerity, Anita and I implemented our own version of software process for start-ups. Later we coined it “Practical Software”. When people saw how we worked, they said “Oh, you use ‘Agile'” and we said “Yes, we are agile” but had never been involved with “Agile”, the new software process movement. Later I took “Agile” training and said “Oh, that’s basically what we used to do.” I found that the while the core of Agile is good, it is missing a lot of the practical basics. Upon retiring, the engineers I’ve worked with are all emailing me about how much they’ve learned working at Azerity and brought with them to Model N. There are lessons learned I’d like to share with a wider audience. Definitely more blogs.

Maybe I’ll finally write that book!

It doesn’t sound like retirement, does it? But then with the Internet, what is “retirement”? Anything is possible.

Is there a role for a Requirements Document in Agile?

My answer is “yes” but not the old type of Business Requirements Document (BRD). I think there is a role for a new type of on-line BRD – one that can easily evolve during the project. Some argue that TDD is replacing this need. But I think there’s a place in the Agile process for capturing the business requirements/information in parallel with the development tasks that ends up on-line and useful/readable by all. It happens DURING the process, NOT up-front.
No documentation

I think anyone who believes in Agile knows that the biggest problem with a big fixed documentation up-front, especially in Word, is that it gets out-of-date quickly and then is just a pile of often-misleading words. OR it’s held as the “bible” and then people become possessive of it and build some big process about how to any requirements mismatches, design flaws, etc. become change request-type issues and there we go – Waterfall all over again.

I believe the BAs/PMs are more likely to feel they can retain project oversight if there’s an on-line tool to track the product backlog (in high-level terms) and bring forward when time to implement it and where you can expand/refactor/capture details as you go along. Where stories can evolve into an on-line knowledgebase/repository that people (like the Call Center, Services group, new hires) can read and reference.

Of course, all projects, Agile or not, have requirements that are (hopefully) based on business needs. Some teams are struggling with their PM/BAs wanting to create a large document at the beginning of the project containing detailed use cases with every possible variation on every requirement. Some are having trouble convincing the PMs/BAs that a Product Backlog with user stories instead of fully documented use cases is a suitable method, with detailed analysis taking place during a sprint.

I think the hesitancy from BAs/PMs is a feeling of a loss of control when they are told to just write down “I want this …” stories, put notes on a board and work “in the air” (verbal communication mainly, not written). Some may argue that is a “lack of trust” – but I argue that PMs are also builders/designers who want to end up with “their” product at the end, their BRD. That still can be a valuable artifact. As long as it’s something that evolves with the product seamlessly and isn’t a wall blocking the project.

That’s where Software 2020 fits in beautifully. The prior blog, “Automatic Documentation – How we use Software 2020 to build Software 2020” describes the automatic way to use Software 2020 for tracking tasks, communicating between the team members (PMs and Developers) resulting in both an outstanding product and nice on-line knowledge base repository (aka BRD).
Software 2020 on-line spec

Software 2020 provides rich text online storage that is:

  • Easy to maintain
  • Easy to track
  • Easy to priortize
  • Searchable and sortable
  • Can Documentation be part of the Definition of Done?

    You might think I’m obsessed with having good specs and system documentation. I’ve blogged about it enough. I’d answer that it’s not an “obsession” but that it just makes good business sense. Even stronger than that – I do not think most software companies can operate effectively without on-line access to the final requirements specification.

    I’m not referring to User Guides or System Administration Guides that can written by tech writers after the software is complete by using the software itself. I’m talking about the specs that capture the business requirements behind what the code does including all of the possible business variations and configurations that needed to be coded for. That documentation is very tough to write after-the-fact, especially if the code is complex and has a lot of parameters, switches and properties to support different customer configurations and business uses.

    Why do we want it?


    Why would we want to end up with accurate requirements/design documents? I asked some key individuals if they thought that requirements management was important. They all worked in a company used to having an on-line requirements management system integrated with their mainline software development process resulting in clean, accurate on-line requirements specifications. Their comments:

    • [Development Manager]: Our specs are absolutely fabulous for requirements tracking and as a reference/knowledge-base. For the entire company. It is a must for any software company…
    • [Developer]: I think it’s critical to have documented what the software is to do so the developer knows what to do and the QA team knows what to test. Having accountability is huge.
    • [Call Center Manager]: Without documented specs, only the developers can support the software – that’s not efficient.

    Why doesn’t everyone have it?


    Why don’t all companies have good up-to-date on-line specifications?

    • It can take a lot of time and effort to keep specs up-to-date
    • Particularly if the spec is written at the start of the project, as the product evolves or changes occur (as they always do), the spec becomes out-of-date.
    • Inaccurate specs are just a pile of words – worthless.

    Because of the above issues/difficulties creating and maintaining good documentation, most Agile proponents advocate doing away with specs. I think that’s “throwing out the baby with the bath water!”

    We developed Software 2020 to fill this void, solve this need. Before Software 2020 we did it with DOORs Requirements Management System and our internal SD Tracker plus a lot of manual effort and manual linkages. But it was worth it even then.

    What Makes a “Good Spec”? Accuracy!


    I’m convinced that to maintain good, up-to-date, accurate specs, producing specs must be part of the process. Developers need to use them while they code. The specs need to be on-line and able to evolve as changes occur from the product owner or from feedback by the developers. They need to be tested for accuracy as part of the QA test process. Every new change needs a link to the coding task that will implement it.

    Good specs are living, breathing documents. Good specs are part of the software process, where the entire team takes ownership and responsibility for their accuracy. That doesn’t mean that there is added work, rather that when used for reference (by anyone – the call center, developers, testers) if the code doesn’t match the spec, a task is created to resolve that mismatch.

    In an Agile environment, why can’t Specs be part of the DoD?


    If specs are just part of the Definition of Done (DoD), two scenarios are possible:

    1. The become inaccurate over time because they are not used during code development, changes aren’t tied to specific code tasks, and aren’t part of the test plan.
    2. ELSE the process could require the Product Owner to add all final changes/updates to the existing specs, the developers to review all changes and QA to verify as part of the DoD. However, this will end up being a significant added cost and I contend that this kind of after-the-fact effort will not result in as accurate or complete a spec as a process where specs are used during coding and during test as part of the process.

    Related Blogs

    Story of a “Successful” Off-Shoring Experience

    “Software Companies need an Off-Shoring Strategy”
    (or so they were saying)

    In the start-up I co-founded, our CEO (and my partner) was pushing hard for an off-shoring strategy. This was the late ’90s/early 2000’s and the buzz in the software business was that the way to grow quickly and cheaply was using the Indian offshore companies. He would regularly send me emails saying “5 skilled programmers for $15/hour” whereas compared to the rates we were paying was a significant reduction. Reading further, there were additional management costs but but still seemed impressive. In addition, this was still during the dot.com boom and local talent was hard to find. (I’d remedied our lack of hires by partnering with a local Indian contracting firm who was providing us with developers where the contracting firm held their H-1 Visas).

    Researching

    I felt inherently that it would be difficult to build a team off-shore but had no concrete reasons for my reluctance so I attended a couple of seminars around offshoring.

    • Many presenters gave facts and figures on the great cost savings. The Indian consulting firms described how cheaply they could provide CMMI Level 5 qualified work. (Since in my early years I was involved in the development and use of SEI Assessments, the predecessor of CMMI, I seriously doubted their Level 5 claims and believe it was more like ISO 9000 where everyone is trained about the steps – how to check in code, how to do code reviews – but not that the development and quality is superior).

    • The large software firms spoke highly of their cost savings. Most had large facilities they owned, operated, and managed where they sent software for final testing or had customer support centers.

    • One presenter discussed how to set up your own facility in India which included numerous lengthy trips to India and the mandatory bribes and dinners with various officials in order to get anything done.

    • Another presentation covered how to set up a “lease-to-buy” program in India, where you’d partner with an Indian firm who would set up a facility, hire resources including management, work with you to train them with the goal of transferring the facility and resources to become employees of the company. That sounded the best but still involved a great deal of up-front negotiations and travel. Until the team is turned-over to your company, there is an overhead fee paid to the services company including equipment and facility costs plus service company fees.

    • I met one person from a small company who swore that offshoring was the way to go. Digging deeper I found that the product expert for their company was located in Russia and he had hired, trained, and was managed their offshore development team from the company’s inception. Their main difficulty was how to train the U.S. Sales and Marketing people but solved it by having Sales and Marketing travel to Russia periodically. An entirely different situation than I was faced with.

    • All presenters from small-to-mid-size companies discussed the high turn-over rates and large yearly increases the region was currently experiencing due to the big corporations, like Oracle, that paid more and that Indian engineers felt gave them better prestige.

    • In addition, the presenters all had similar statistics regarding the number of managers needed per developer, additional cost for up-front design, and percent slower ramp-up of skills resulting in less productivity for longer duration.

    I documented my findings regarding what it would cost our company to set up a reasonable off-shoring arrangement versus hiring locally. Being a start-up with very few people, none of us would have time to travel to India and do the full-time effort required. At our early start-up stage with only Angel Investors we did not have the capital to initially buy a building so I analyzed the “Lease-to-Buy” option with a three-year turn-over. Besides the actual developer hourly rates, costs include:

    • A new local manager position (part-time)
    • Significant travel budget
    • Service company overhead and fees
    • Local manager
    • Average turn-over rates for India resulting in additional new hire travel, training and resulting loss of productivity during ramp-up
    • Yearly increases
    • Loss of productivity of the local team’s time that would need to be spent with remote conferencing, training, and travel
    • Average productivity and quality figures

    Needless to say, the yearly costs were nearly equivalent to hiring less developers locally and didn’t improve significantly after the group became employees, although at that time the potential to lower turn-over rates due to stock options and other benefits increased.

    Conclusion

    My CEO agreed. It was an invalid business proposition. We hired locally.

    New Company – New Strategy

    When our start-up was acquired, the acquiring company had an outsourcing strategy in-place for its existing product line. Their offshore team performed testing only. Because of the size of that product’s software platform, each remote tester required local hardware and software requiring extensive Build & Release personnel and policies and high-speed dedicated networking from Corporate to India. The company had decided that the city they’d chosen was not a good choice, suffering from high turnover but lack of local talent pool. Plus the infrastructure there was not sufficient.

    They chose a new partner in Hyderabad for a Lease-to-Buy plan. Their goal was to move all development and maintenance to India with the exception of new technology development. I was given directions to develop an offshore team for our product line as well.

    Prep Work

    I hired our company’s prior VP Engineering as a consultant to help me with the initial 3 months effort. Together we put together the hiring plan. She coordinated updating and enhancing the Developer’s Handbook and other on-line documentation and development guidelines. She updated our software process to incorporate the offshore efforts and put together the training program and travel requirements. Fortunately we had a very good process (many of the tenants of “Agile” but not Scrum). We had good tools to aid with the process: Our proprietary tracking software (SD Tracker), PerForce for code check-in, and Telelogic’s DOORs Requirements Management system (since purchased by IBM). All three had web-based interfaces which was key for remote development. SD Tracker had ongoing comments section which greatly aided on-line “discussions”, capturing what was discussed and decisions made.

    On-Boarding

    We would start with only two developers, one tester and one manager who would also need to do hands-on development part-time. The other product line was much larger and had a significant hiring plan. The two product line teams, though, would remain independent since the code was very different. The hardest position to fill was the overseas manager. He/she would be key to the success of the project since he/she needed to be technically skilled to lead and train the new hires plus a good manager. I quickly learned that in India, the engineers do hands-on development work for only a few years then have the goal of becoming a manager. Managers there do not do hands-on development work. Finding someone willing to do both took a lot of convincing, but we were finally successful. The developers and tester were also hired and all four came to California for two months training. The manager had family in India and ended up having to return after six weeks. We were fortunate that he was extremely bright, picked up the basics and the deeper requirements, and although he still was a bit reluctant to go back to development, agreed to try for a year at least.

    After the team returned to India, there was a focus on continued communication. One of the lead developers was given responsibility for managing the Indian team half-time (coding the other half). She traveled there and spent a month on-site. Upon her return she regularly scheduled nightly conference calls weekly or more as needed.

    End-of-year Statistics

    Regardless, ramp-up was slow for the developers. After one year I found the developers were only 20% to 30% up-to-speed whereas in one year local new hires would have been at least 50%. (The software was complex). I also tracked the time I was spending providing additional design documentation versus what would be required locally but also many questions that seemed to require a simple written answer ended up looping several days before it became clear or a conference call was needed.

    After a year, one of the developers was deemed unable to perform and was moved to our services team to work on implementation code and a new developer hired and both developers were brought to Corporate for training/re-training. The manager was unable to travel due to personal reasons but had proven himself to have been a valuable hire. A few months earlier, at the end of our release cycle, his team was not able to complete some of their assignments and he jumped in and completed not only his own but any outstanding work. His code was reliable and high quality which is the only reason the release was successful. At that time I discovered that the services company was paying the manager the same low rate as the two developers (since he was also developing) instead of the manager rate I’d agreed to. I was furious and demanded they immediately provide him the raise and feared losing him so also spent time talking to him and making sure he was happy and letting him know how pleased we were with his efforts. Over the next few years the team was expanded slightly (3-4 developers, 2 testers) with the average amount of turn-over and salary increases. The manager remained.

    Ongoing Travel, Communications, Travel, Communications

    People were continually going to/from India. Any of our Indian engineers who traveled home yearly would take an extra few weeks to go to the site to work/train. All managers (including Directors, VPs) went there at least yearly. The CTO moved to Israel where he was responsible for all Indian operations. Plus yearly we would bring everyone to Corporate to work for a month or so.

    The company implemented it’s “Buy” option and all of the offshore team became employees. Plus they have been raming up the size of the offshore team.

    Changes Needed with Agile

    Then the company introduced Agile. Initially they tried to use the DOORs Requirement System to capture Stories in a separate spec but that was not a good process. First, DOORs doesn’t have an easy way to prioritize and sort requirements so the Product Marketing team (who performed as Agile Product Owners (POs)) exported the Story doc to Excel then went back to update DOORs with the Story Points and other changes agreed to in team meetings. They still needed to update the actual product specs in DOORs and now the tasks in SD Tracker were linked to stories and specs. But the biggest issue was the difficulty in working with the offshore team starting with Stories. They were used to working from detailed specs and the added interaction between them and the POs caused significant time delay. The company smartly decided to hire POs in India to work locally with those teams. For the next release, the company moved to Rally for Agile Story Management. This was much better than DOORs and Spreadsheets since Rally had a prioritization tool and the features one would want to manage Agile Stories. But, unlike real product documents, the Agile Stories, though grouped in Epics, don’t maintain a specific logical readable order – they remain distinct stories. In order to still communicate the business basis, the POs first wrote extensive PRDs using Microsoft Word. Those would be attached to the Epic. The features within the PRDs became Stories in Agile. In order to provide better clarity, extensive Conditions of Satisfaction (COS) were added as validations. To accommodate this, a design sprint was added as Sprint 0. Of course, quickly after the project started, those stagnant Word documents became out-of-date and useless.

    Both product line’s Product Management and Engineering Management and the VPs of both organizations spent several weeks in India to kick-off both new releases Sprint 0’s and to train/re-train. Having a local PO improved (but did not eliminate) communication issues since the Indian PO while very intelligent and eager, had a significant amount of information to learn before he could be effective. Local Product Marketing managers typically took 1-2 years to become effective and still didn’t know the breadth of the product after that time but had local product experts to interface with which the offshore PO did not. While I believe a local team could produce deliverable code in a sprint, the use of locally disperse teams requires the addiction of 3+ “Test Sprints” after code complete. This then is more of a hybrid model than strict Agile but seems to be working fairly well. The Product Line has two separate Agile teams including PO(s) and Scrum Master – one at Corporate; one in India.

    Same Conclusion

    Bottom line – I think this offshore team is as effective as anyone could hope an offshore team to be. A form of “Agile” is being performed, although it is currently not as effective as our prior Practical Software Methodology (an Agile-like process) with a single local team.

    There is substantially no cost savings overall.

    There is more work for the POs and development manager than interfacing daily with a local team plus ongoing travel costs and interruptions. Particularly when “Offshore” is half-way around the world and trips there require weeks due to travel time.

    More effort to complete, more miscommunications, less product delivered.

    What is “Respect”

    In a LinkedIn thread, someone asked “what is ‘respect’ in the Agile context?”

    What is a sign of respect?

    Since Agile is team-based, an obvious trait of any well-functioning team, Agile or otherwise, is showing respect for each other. And, after years as a professional, it seemed kind of intuitive to me what “respect” in business is and the same applies to Agile.

    However, is it intuitive when there are cultural differences – either global culture differences or workplace cultural differences?

    1. An American had held several meetings in a remote Japanese village. He was on the train returning to the city but had fallen asleep. When he awoke he was sitting by an elderly Japanese man. He said “Have I missed ‘X’ stop?” The man said “No”. A couple of stops later the elderly man got off the train. At the next stop the few remaining people in the same car left. At the next stop the train stopped. The American found a conductor and asked why the train had stopped. He said “It’s the end of the line.” “What?” said the American. He was furious because he had, it seems, only missed his stop by one and could have easily walked back but now needed to purchase another train ticket or find a taxi. Had he been Respected? Disrespected?

    2. There was a discussion about if it was respectful to shorten or change someone’s name into a nickname they did not use. Or to misspell or mispronounce someone’s name. I was reminded about when I was part of a business meeting with gentleman from Japan. We had been briefed as to the traditional meeting protocol.
      The Tradition of Bowing

      At the beginning of the meeting, the representatives from both companies formed a line and one by one as each Japanese businessman came forward they met each person from our company by exchanging business cards, both bowing, and each reading each other’s name from the card, starting with the host. We had business cards printed with English on one side, Japanese on the other. The first man came forward and presented his card. We bowed. I took his card and read his name. Then I presented my card with the English print facing up and toward him. I was to hold it with both hands by the upper corners. Lean forward slightly to bow while offering the card. He took it, flipped to the Japanese side and said “Jan Makuru-san”. Totally mispronounced my name. Respectful? Disrespectful?

    3. In the afternoon during the same meeting with the Japanese businessmen, I was presenting. The lights were low for the projection, the room warm and hum of the projector in the background. Two of the five businessmen were sleeping. Respectful? Disrespectful? Room too hot? Or was I just boring?

    4. More sleeping-on-the-job: It was a Sales Off-Site for a small U.S. start-up. In the morning, the CEO/VP Marketing was giving the presentation explaining the product direction and overview of the sales strategy. He noticed a newly hired Sales Director was asleep. Respectful? Disrespectful? Or was he just bored?

    5. I was newly hired as Director of IT Technology in a company that had only had a few newhires in the IT organization in many years. Most of the members of the IT organization had been with the company 10 years, 15 years or longer – most in the same job for as many years. Part of my responsibility was SAP Basic and two of my system engineers came to me to say they found that last night’s backup had issues – they feared the backup tape drive was failing. They told me who they used for service and could call and have them come in. I said “Great, have them come in as soon as they can”.


      One of the engineers said “Right now?”

      I said “Yes, if they are available.” I wanted to be sure if there were parts needed or any other issues we had the best chance of getting the tape drive ready for tonight’s overnight backup.

      They said “Will do” and started walking away to make the call. Respectful? Disrespectful?

    Back to the first example. Was the elderly Japanese man being disrespectful? The conductor explained to the American – “In our culture, the worst thing you can do, the greatest disrespect, is to cause someone else anguish or grief. He knew you missed your stop but if he told you that would upset you. He would never do anything to upset you.” He was not being disrespectful.

    What’s in a name? If someone says “Hi Kev” and his name is “Kevin”, is that disrespectful? It depends. Were they doing it in a “buddy/buddy” way, to show familiarity? To show friendship? If so, it isn’t disrespectful (unless Kevin tells everyone he “hates” to be called “Kev” and they keep on doing it to aggravate him). Are they saying “Hey, Bubba” to annoy you? Then yes, it’s disrespectful. If you mistype someone’s name is that disrespectful? No, it’s a typo. Was the Japanese businessman being disrespectful? Of course not! There are many syllables that do not exist in the Japanese language, particularly difficult is the distinction between our “l” and “r”. Adding “-san” at the end is the formal form of respect. So yes, he was being very respectful.

    Sleeping on the job? It depends. I knew the Japanese businessmen would be sleeping in the afternoon – had already been briefed and told not to worry about it. It’s common practice. They do a quick nap after the noon meal and wake up and quietly whisper to get caught up on anything they may have missed so at the end they are all still up-to-speed. Was it disconcerting? Yes because they were either sleeping or whispering. Did I take offense or feel disrespected? No – because I understood the cultural norm.

    How about the new Sales Director? He was fired shortly after. Not for the one transgression but it was the last in a series of attitude issues that demonstrated his lack of seriousness in learning the job. The once-a-year Sales Training delivered by the CEO himself is the very best place to gain understanding about the company, product, and sales value. Sleeping through that was unforgivable and the last straw. (And it definitely was NOT a boring presentation!)

    That last one was a bit of a trick question until finding out more. I saw a glance between my two system engineers as they left and called them back. I said “Was that not the right choice?”

    Their eyes got wide and both were “Huh?”

    I said “Is there a reason not to do the servicing now?”

    One replied “Well, to service the tape drive we need to shut down the production servers.” I was not familiar with these HP systems but others I’d worked with allowed the tape drive to be taken off-line and reassigned without the system having to be shut down.

    “It’s only 2 PM, we can’t bring manufacturing down now. Is there any reason you would not want to do it at 6 PM instead?”

    He replied, “6 PM is when we would do it.”

    “I have to ask, why were you going to bring them down now then?”

    “Because you told us to. Our last boss would have yelled at us if we didn’t do exactly what he said.”

    “Even if it was the wrong thing to do?”

    “Yes – he never wanted to be wrong. We could get fired!”

    These two were definitely showing respect upwards. But their old boss had not shown them respect going the other way.

    Is there any difference between respect in an Agile Team and respect in general? Respect in an agile team or any good professional relationship is a two-way street. In a top-down management heavy culture, the employees may show respect to their boss (as in my 5th example above) but if their boss doesn’t show them the same respect (by listening to their inputs, asking for their suggestions, and letting them learn and grow) it isn’t a culture of respect.

    So what is respect? The list is longer than this but here’s a start of what I think are the most important aspects.

    • Working to communicate clearly. While the elderly Japanese man’s actions are explainable for his culture, the goal is for the entire team to have a common basis of understanding that it is not “bad” or “disrespectful” to communicate if there are issues in the code or other problems – that that is “good” because it keeps the issues from the customer.
    • Asking for/accepting input. This is the two-way-street of communications.
    • Listening to input without criticism. (Also referred to as ‘Attack the problem, not each other.’)
    • Communicating honestly, but with tact and care for each other’s feelings.
    • Evaluating your own feelings. If you are offended by something someone says (or feel disrespected), first step back to question if it is disrespect or lack of understanding. Lack of understanding can indicate either incorrect/incomplete communications or cultural differences. Go back through the first four bullets above to see if you are communicating and caring for each other’s feelings.
    • Working as hard as you can to do the job you have been assigned.
    • Doing as much as you can to help people you work with.

    And after further discussion on LinkedIn, this seems like a good set of principle defining “What Is Respect in Agile?”:

    • Communicating clearly in a way that leaves no possibility for doubt on intent
    • Communicating honestly, but with tact and care for each other’s feelings
    • Working to continually improve the way the team functions and interacts
    • Communicating both ways – asking for and accepting input, listening to input without criticism
    • Being supportive of team mates
    • Being considerate of each other and the customer
    • Trusting each other to do the right thing
    • Working hard towards a common goal – contributing to the fullest extent towards the technical excellence of the product

    Any healthy work environment requires respect both ways!

    Confessions of an Agile Blogger

    I’m back to blogging now having returned from our great 6-week trip on our new boat in Canada.
    Pender Harbour, BC, Canada

    I have been contributing to various Agile LinkedIn and other forums – about what works in Agile, what doesn’t. Whether or not Scrum = Agile, if you can offshore and be Agile, how to develop with agility, etc., etc.

    The funny thing is that what I blog about is more often my experiences with our “Practical Software Methodology”, not “Agile”. From what I see in blogs and discussion groups, “Agile” (with a capital “A”) means Agile/Scrum or Agile/Kanban – strict adherence to every step and recommendation like a religion. Whereas there are a lot of processes that can follow the Agile Manifesto’s tenants and principles and not be Scrum or Kanban. I call those “agile” (little “a”) or Agile (without the quotes). I think they are realistic for the majority of today’s software projects.

    “Practical Software” was the process implemented at Azerity, my start-up. For years prior to starting Azerity, my goal was to take the best practices learned at Ford Aerospace on Government projects plus leverage the work we did with Carnegie Mellon on SEI Assessments (now referred to as CMMI) but throw out the bulk resulting in a lean and clean process for start-ups. As my start-up company grew I was able to hire a top manager from Ford Aerospace and together we implemented the tools and processes we later coined “Practical Software”.

    With our Practical Software Methodology we were iterative, produced code quickly, short release cycles, high quality and high customer acceptance. In parallel, we maintained our on-line DOORs requirements specs, our “bible”, which were part of our process and which were accurate, tested, used by developers, QA, the Call Center, and Consulting. When we sold the company, the on-line DOORs specs were key to the value of the IP. Other developers could be hired, people come and go and even I could quit and the DOORs specs lived on. We were able to maintain those accurate documents with minimal cost because they were part of our development cycle and were iterative. They were not big waterfall Word docs but living breathing statements which matched the tasks assigned to developers to implement/update.

    • We were small and we honored individuals, required feedback and interaction. Our process and tools supported and enhanced the interaction, didn’t detract. We had no organizational silos. There was no throwing of documentation over the wall to the development team. We were a cohesive, single entity building an exemplary product. Quickly. With very few engineers.
    • Our goal was working software since that’s what the customers wanted and what we were paid for. Our process required us (me primarily) to have the documentation/specs to be in place in time for testing but the docs were a reflection of the code, not the up-front mandates from the waterfall era.
    • Because two of the three co-founders plus other key members of the company came from the customer’s industry, we had the unique advantage of knowing what the customers in our space wanted so the software was accepted and loved by our customer base.
    • Because I was one of the co-founders, I had the “red pen” and could slash out features if we needed to make a hard release date or visa versa, move the date if needed; thus able to respond to changes, not follow a fixed plan.

    We followed the Agile Manifesto tenants:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    Agile and it’s related methodologies (XP, Scrum) were born in parallel to Practical Software. I was previously a skeptic about Agile because whenever I heard someone talk about implementing “Agile”, they also added “throw out documentation”. Just talk. Sticky notes on a white board. Since my background is building large-scale mission critical software applications with extensive business practices and policies incorporated in the code, where the product was already so large even I was having trouble remembering every business requirement, I couldn’t envision how our product would/could ever be managed, evolved, and maintained. Plus our process which included on-line documentation was so clean and efficient it was hard to understand why other companies were struggling. (I’ve since come to realize that others haven’t found the secret sauce – how to maintain documentation in parallel without impacting development timelines).

    A few years ago I was converted from an Agile skeptic to a proponent. The company that bought Azerity was implementing Agile or a hybrid thereof. I became a certified Product Owner. The interesting thing about my Agile training was that my objections to Agile ended up being objections to some form of Scrum or to a misunderstanding others had of the Agile principles or to some other misuse of Agile tenants. In reality, what I learned was that at the core of Agile (the Manifesto) were the very concepts that were at the core of Practical Software. Which makes sense. The initial proponents of Agile were seasoned software professionals who looked at how waterfall/phase-gate projects were being done, saw the issues, and proposed a better way. We at Azerity looked at how the big government waterfall projects were done, saw the issues, and proposed a better way. Many if not most of our findings were consistent.

    I now believe the industry is being improved overall by the consistent message and training coming out because of Agile. I still see issues in the Agile communities:

    • There is still a tendency for some to convert the statement of “Working software over comprehensive documentation” into “No documentation”.
    • Scrum to me seems too rigorous to have innovative iterations on a less structured schedule.
    • Agile seems development-focused and thus loses some of the bigger-picture concerns such as delivery, customer upgrades, other organization’s needs.

    Both Agile and Practical Software solved what I saw in government and commercial software companies as the main issue – the issue of organizational silos and phase-gate workflow. “Business people and developers must work together daily throughout the project.”

    I am now an Agile proponent (or should I say “agile” proponent). Please excuse me if I’m sometimes blogging about my “Practical Software” experiences ☺

    See how we automate documentation with Software 2020

    To better describe how Software 2020 can help you create your As-Built documents as a by-product of your software development process, automatically, here’s how we used it when we built Software 2020. Of course we couldn’t use it from start-to-finish like we recommend you use it because it wasn’t built yet ☺ But we proved how great a tool it is and will continue to use it as the product evolves.

    I first wrote a spec to capture my thoughts and ideas since there was no Software 2020 to put my ideas in but we used it as a guide, not as firm requirements. Freeman is so creative that when he doesn’t need to follow a spec exactly we get better products. Similar to why Agile proposes fuzzy stories which evolve into the final firm specification. We work best as a team when we can iterate and evolve the product as we go along. We’re agile.

    So we started fuzzy (like you would with Agile stories). I want a “Task Tracker” tool like our prior SD Tracker (proprietary) tool. I want another document-type, Word-like “view” of the subset of tasks that were requirements or “specs”.

    I’ve built enterprise application software for years and managed those efforts, using a combination of tools and proven processes that allowed us to build products quicker, better, and with less people than other software companies could in our field. Our techniques and approaches have withstood the test of time. I knew how I’d like one tool to solve the holes and issues I’m seeing in how companies use tools today: Agile Story Managers, Task Trackers, Requirements Management Tools – and definitely better than what is used in Agile teams that don’t like tools: Word, Excel, Story Boards. I had a good idea of what I wanted. Freeman had great ideas about the new kind of architecture he wanted to build.

    The Tracker module was completed first since we had a clear starting place, improving the SD Tracker tool we built at our prior company. We started our project in October and by December the Tracker module was functional enough to use it to enter all of the development tasks in. I took the list of spec/tasks we’d been working from and entered them in the Tracker and from then on we worked as we always have in the past: Nothing gets coded unless there’s a Tracker Task for it and the task is assigned “open-fix” for development, set “in-progress” when work begins, “resolved” when on our integration system ready to test and “closed” when I’ve tested it.

    Since by this point were already screens built for the Tracker, we started working to make sure those matched my ‘ideas’ and had some minor corrections. For example, the first task I entered in the Tracker, #1001, was a clean-up task:

      “On all screens, in the white top banner, there shouldn’t be a title/words between the logo and tabs (now shows dash + Page Title + User’s Name). Instead the Title should be white and centered…”

    As we did the clean-up, we evolved this task to capture the final requirement for screens in the Description of the task:

      “There are three types of screens: Summary Screens that present batched sets of information, Detail Screens (Task, Person, Client), and Pop-Ups (attach a New Attachment, Set Defaults, etc.)

      “On all screens, in the white top banner, there’s the Software 2020 log on the left and Navigation (Nav) buttons on the right. The first Nav link goes to the user’s Profile. The user’s name should be shown as ” Profile” in the tab bar. That way tech support knows who the user is but the screen is cleaner.

      “Below the white banner is a blue Title Bar. The Title should be white and centered in the blue title bar.”

    Once we had an “Organize View” feature in February 2012, I selected tasks that represented requirements, like the one above, #1001, and linked them to the appropriate spec until all tasks that represented requirements were in organized specs, by module. Here’s the current Software 2020 Spec List:

    Or closer up view:

    When I drill into the Look & Feel spec I see this:

    Note that it looks like a nice word document (embedded graphics, etc.). That first task, #1001 is there. If you look at the entire screen you can view task information to the right so it’s not just a Word Doc but is a nice way to view, and update spec tasks:

    Now I have all of the information about what was built, each and every task, in a nice readable set of specs. This is so much easier and better than trying to maintain a separate Word document or even update requirements in a linked tool. And definitely an advantage over having no documentation at the end except your pile of yellow stickies and code, regardless of how well commented and structured the code is.

    Some advocate the Test Driven Development (TDD) approach. I agree there is benefit to TDD and would like to have a Test View on the same set of completed tasks to create test plans from. But disagree that TDD alone would replace real business-oriented requirements specs.

    There’s a “Download” button if you want to save versions as Word docs, Excel spreadsheets, or an HTML page that you could store on a central server after each release to have a set of documents reflecting exactly how that version was built.

    Then, as the Product Owner, I can add new features for the next release as Stories or requirements right in the Organize View (which is how I like to do it because it’s organized and logical, like a spec or word document) and they show up as tasks in the tracker. I could also, for new features entirely, create a Story Spec and put Themes / Epics / and Stories there.

    New spec tasks and any other tasks (bug fixes, maintenance tasks, etc.) assigned to a release can have Story Points or time estimates entered and can be easily prioritized using the Ranking Tool:

    Once ranked, the team can assign to Sprints and there’s no re-entering of tasks needed, no extra work.

    Prior to Software 2020, we spent 10 years developing robust, secure enterprise application software using the prior SD Tracker tool and the Teleogic/IBM/DOORs Requirements Management System. Our software competed with the big guys – Siebel, Salesforce, SAP, Oracle – and won. Our process and toolset worked effectively but had manual steps and we didn’t have Agile story management tools.

    Using Software 2020, the “One Tool” to do it all, is so much cleaner, easier, more efficient, and because of the automatic linkage, clearer for the developers than having to use a tracker then open a requirements spec, look for the links, etc. The task has the link to the spec – one click and they see this task in context with other related information (tasks related to the same function, screen shots, etc.)

    For Agile teams, for the first project you would enter Stories grouped under Themes and Epics in the Organize View. Software 2020 provides nice Agile story management tools (charts, ranking tool, story point calculator) to help organize the sprints. As the story evolves, if the PO simply keeps the task/story description up-to-date, and, because it IS the task the developer is working on, there’s no mis-understanding. Because that description is on the task the developer is working on, both the PO and developer can easily view/agree that the description does match the code. There isn’t a separate “Requirements Spec” to maintain. Nothing to get out-of-sync. It’s automatic.

    With Software 2020, the company obtains the benefits of having good systems documentation without any added work.

    See how our new tool, Software 2020, can produce automatic documentation as part of the project.

    How to Document Software in the 21st Century – “Organize” View

    (Copied from Software 2020 Blog)
    On a recent LinkedIn post, people were saying “we still struggle … when it comes to testing and documentation” and not having good design documentation “creates difficulty for the software testers to come up with tests …” and that “In regulated environments, documentation is a must … and most important tracing from requirements to design and tests.”

    I think you can have both. I believe having traceability from the design specification to tests and ending up with an accurate “As-Built” Spec is a “must” and valuable even in Agile environments. What “isn’t” Agile is expecting everything to be completely designed up-front. Rather I believe in evolving the requirements (or fuzzy up-front stories) but at some point the task must become clear enough for implementing.

    My friend and I were VP Engineering and CTO respectively at my software company. She and I had both come out of the Aerospace industry and wanted to take what we’d learned and throw out the unnecessary steps to create a light-weight, high-quality process for start-ups. We called our process “Practical”. People who saw how we worked said we were agile. One key was we integrated an on-line requirements management tool tightly into our process. I’d update the new features in the on-line specs. Some would be complete up-front if the change was well-know and researched. Other times there’d be a placeholder – “We want a configurator”. Developers worked from these on-line specs. We were iterative – sometimes the specs evolved with the prototypes and the inventiveness of the developers but before testing started, the specs had to be finalized. Testers tested against the spec updates. I had a lot of manual work to link tasks to specs and make sure the wording was always up-to-date as the tasks evolved. But well worth it. The whole company leveraged those on-line specs. Extremely valuable.

    But I always yearned for a better integrated tool where the story was automatically a task so everything was in one place. And as the task was split, refined it stayed organized, like in a spec so at the end I had accurate, on-line description of the actual deliverable product.

    Companies now embracing Agile (completely or some hybrid) start with an Agile Story Manager tool and often need to re-enter tasks into their tracker. In companies that used to have good, integrated specs as part of their process like ours, those specs are becoming inaccurate, aren’t used by developers to code from and aren’t tested. Worthless.

    We built Software 2020 because of these needs. It’s the tool I’d always wanted and we’ve been using it to build the tool itself (how’s that for iterative 🙂 There’s an “Organize” view that lets you structure your stories in a word-like doc (you could start with themes and epics but if you had an existing organized view “spec” you’d add the new features in their proper place) with screenshots, etc. and each specification is automatically a developer task. You can update the description of the specification as design is clarified either in the “Organize” view or regular task Tracker screens. Later we want to add another “view” for the test center. That gives the linkage the regulatory projects need – automatically. But even for non-regulatory, even on our little tool-building project, my architect/developer is already finding the value of looking at the document view of my design spec, in-context, to better understand the new features I’m designing/asking for. So I think we can be Agile and have nice documents too.

    Who Needs Documentation?

    I posted an Agile LinkedIn discussion group question Where do you go to see what the code really does besides asking a developer to start a discussion about the role of specifications in the new Agile methodology. The discussion threads have been interesting and lively (LinkedIn, group “Agile”). So I wanted to answer the question posed numerous times: “Who would use that documentation and why/how?”

    First, I’m not talking about old, antiquated waterfall design specs that are soon out-of-date used by no one. I’m talking about living, breathing hierarchical information (in a central tool accessible by everyone) that represent the repository of product knowledge: protected, validated, for use by the entire organization. Documents that everyone in the organization takes ownership in and uses. A cool set of “shiny docs”.

    I can answer later how it could have been done (seems it’s not done at most companies and recent surveys say 83% of companies at best use Word Docs to describe their requirements) – but for argument’s sake, trust and believe there is a repository on-line specifications (“shiny docs”).

    Who uses our current on-line specs and why do they need them?
    a) For the developers – for the new guy, not as a replacement for training and not a static user manual – rather a handy reference area to delve into for more detailed, complex functional understanding, even some design details. A wiki for the product, helpful even for the most experienced developers.

    b) Technical Support (TS) (the Call Center) wants to be able to quickly identify if a customer request is a bug, training issue, or if it should become a new feature request. They do their initial investigation using the specifications and replicate the issue in-house if they believe it’s a bug (so they help identify if it’s a customer config problem or base code). For non-bugs, they use them to understand how the product was designed versus what the customer is requesting to give better feedback to the PMs and better represent the customer’s business position for the change versus what’s there. Having a knowledgeable TS team that can get accurate information about all features in a very large enterprise application streamlines getting real bugs and issues into the product development releases. It’s much quicker if everyone knows/agrees a fix is needed than if something just sits on the backlog pile until the next PM release review cycle. Customer satisfaction is improved with clear feedback about if a ‘fix’ is feasible and how quickly. Some product changes can’t be immediate. Customers get that. Clear communication either way improves customer satisfaction.

    c) The Product Management Team: If you are a Product Manager for a huge enterprise application and need to add new features and functions requested by customers to an older module with tons of business functionality, you probably don’t know everything about what the product does or even all of the history about what it should do and why customers wanted it that way. The online specifications help immensely.

    If such documentation could be produced automatically as the result of the development process – wouldn’t it be useful? Why not aim for that?

    We don’t need separate tools

    (Posted to Duck Pond from Software 2020)
    Aren’t new enhancement requests, stories, bugs, and requirements all just “Tasks”? And instead of all the different tools today — Agile Project Backlog Management Tools, Bug Tracker Tools, Requirements Management Tools — shouldn’t those be just different views to manage these (or subsets of these) “Tasks”? I think so.

    Story Boards, Requirements Specs, Bug Tracking Tools are all just different views of “Tasks”.

    Given that perspective, a modern robust Tracker would manage all “Tasks” (whether they are the new Agile Stories, bugs, client issues, etc.) consolidated for team tracking and estimation to complete reports considering the team’s vacation calendar and all of their work combined.

    Then modern Agile tools could help plan new releases taking into account information about the developers’ other work (hence their percent availability) and provide a better estimate of completion for the current sprints and releases. Useful tools then would help manage the current release (in Agile, that’s Story Boards and organized hierarchical views – grouping tasks into epics, stories and their children). And facilitate the team’s management of these Tasks as they move from concept to delivery.

    But keep them in the bigger database of “Tasks” so managers can manage the team’s full effort, not just the current release.

    That’s what Software 2020 does.