“It Starts with an Idea” is finally published and available on Amazon – Click here.
Read about the adventure of a start-up in Silicon Valley. The book interlaces the story of the start-up Intelic (renamed “Azerity” in 2001) with stories from prior jobs, valuable lessons learned. The book reveals how Intelic created a dedicated and enthusiastic team – a team that worked hard and had fun – and a great product.
Draft copy of “Practical Software” being reviewed! (UPDATE: We changed the name to “It Starts With an Idea” before publication)
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.
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.
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 provides rich text online storage that is:
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.
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.
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 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).
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.
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:
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.
My CEO agreed. It was an invalid business proposition. We hired locally.
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.
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.
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.
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.
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.
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.
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.
In a LinkedIn thread, someone asked “what is ‘respect’ in the Agile context?”
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?
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?
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.
And after further discussion on LinkedIn, this seems like a good set of principle defining “What Is Respect in Agile?”:
Any healthy work environment requires respect both ways!
I’m back to blogging now having returned from our great 6-week trip on our new boat in 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 followed the Agile Manifesto tenants:
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:
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 ☺
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:
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.
(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.
Jan McCleery - from the Duck Pond 