![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Lean development is a culture; waste reduction is just one of the results. It's true that removing waste can improve operational efficiency, but much, much more important than this is that it is an enabler to shorter cycles, thus providing value to the customer sooner in a way that doesn't overburden staff. These shorter cycles can improve competiveness and responsiveness in the marketplace. They can also provide a valuable opportunity for learning and continuous improvement for the development teams.
Although this article focuses on how the IBM® Rational® solution for Collaborative Lifecycle Management (CLM) helps to reduce waste, it's also important to remember that this is just an enabler for people. Face-to-face interactions -- going and seeing projects in action and thinking about the root causes of problems -- are also vital aspects of the lean culture.
Indeed, the Toyota president said that the two pillars of lean management are continuous improvement and respect for people:
"The essence of [the Toyota system] is that each individual employee is given the opportunity to find problems in his own way of working, to solve them and to make improvements" -- Inside the Mind of Toyota Management Principles for Enduring Growth
This article cannot possibly do justice to all of the philosophy, thinking, and impact that the lean approach has had on the software development industry. For that, we recommend reading Lean Software Development: An Agile Toolkit for Software Development Managers, by Mary Poppendieck and Tom Poppendieck (see Resources).
We have structured the article using the types of waste defined by these authors:
- Waiting
- Time spent waiting, which is one of the biggest wastes in the software industry. This could be while you wait for other people to do something, and it is often caused by poor hand-offs between teams.
- Motion
- Time wasted by people and artifacts moving. How easily accessible are subject matter experts? Customers? Can the developer find the results of the tests without walking down several flights of stairs to another office? Where are documents? How are hand-offs managed?
- Extra features
- Time wasted implementing something that is not needed to solve the business problem.
- Task switching and hand-offs
- Time wasted by switching between lots of tasks, [thus] wasting time switching contexts and resetting environments, not to mention that this will result in more partially completed work. Assigning people to multiple projects is a potential source of waste.
- Partially done work
- If a story or use case scenario is not complete and free of defects, then it has little or no value. It's not possible to know if it works in the production environment or whether it will provide value to the business.
- Extra processes
- Time wasted by following unnecessary processes, or time wasted because you have to repeat things unnecessarily or create unnecessary paperwork. Extra paperwork is a classic example of potential extra process. It's worth asking this question: Is this paperwork actually providing value to the customer?
- Defects
- Waste caused by the fact that defects prevent work being completed. Also, the effort to fix them, especially if the number of defects is allowed to grow and the project has significant technical debt (see the Defects section that follows). The sooner the defect is detected and fixed, the less waste it creates.
The article focuses on how the key Rational CLM capabilities address these wastes , including the list of products that follows. The individual products are not referenced because the purpose of this article is to focus more on the overall capabilities of CLM that help solve particular problems. We recommend looking at the excellent resources on Jazz.net and IBM.com to learn more about the products themselves. (See Resources):
- IBM® Rational® Asset Manager
- IBM® Rational® Quality Manager
- IBM® Rational® Requirements Composer
- IBM® Rational Team Concert™
You can skip ahead to sections that interest you most or read in sequence. The Measuring value chains and Defects sections are especially useful, because they give you tools for analyzing and thinking about any processes, with defects being an example. So if you are going to read only one or two sections, we suggest those two.
A lot of waste can be attributed to waiting. This is usually because teams and organizations don't prioritize their work based on the impact to others. This, in turn, is because there is no simple way for a team or individual to understand which aspects of their work impact others. The scrum method tries to tackle this by having daily stand-up meetings focused on impediments. However, this approach is difficult to scale to distributed teams.
The IBM Rational solution for Collaborative Lifecycle Management, or CLM, provides several key features for reducing the time wasted by teams and individuals waiting for others. First, it is a simple process to mark a task as being blocked by another task. Teams and individuals then monitor three views: my blocked tasks, my tasks blocking others, and my tasks recently unblocked.
Figure 1. Blocking tasks
This approach dramatically improves the visibility of your pieces of work that are blocking other teams and individuals. This visibility is the first step to letting teams self-organize to reduce waiting time. At a program or project level, it can then be useful to monitor the number of blocking tasks by owning team. Having this on a team's dashboard helps them learn and adapt their approaches to minimize these impediments.
Figure 2. Blocking tasks by team
In development, there will be occasions where a task being worked on is blocked and progress cannot be made. In this situation, a task can be suspended. This allows the unwinding and storage of all the code changes related to the task. After a task is suspended, the developer can then work on another task. When the original task becomes unblocked, the developer can resume the original work (and merge in the changes from the original task, if required).
It's possible for a developer to have a large number of suspended changes or change sets. (A change set is a repository object that collects a related group of files, folders, and component modifications so that they can be applied to a flow target, such as a workspace or stream, in a single operation.) However, don't get too carried away, because each suspended change set represents waste in the form of unfinished work, but as long as the developer is working on valuable work, this form of waste is less of a concern. This is an example of temporary necessary waste that could be analyzed in a retrospective.
Finally, reviewing artifacts can also result in a lot of waiting waste, as the authors often have to wait for reviews to finish before they can proceed, and they can often waste a lot of time chasing people to complete reviews. CLM makes this a lot easier by centralizing and automating reviews. This means that artifacts for review (requirements, design, code, software assets) can be assigned electronically to a reviewer, and their comments captured and implemented in a simple fashion. Reviewers will be notified and reminded of reviews automatically. It also makes it possible to see the status of any review at any time. This makes it easier to understand which participant needs to be chased to complete a review or which review items are creating problems.. This approach can remove a lot of waste from the process of getting artifacts reviewed, both in terms of motion waste and waiting.
Figure 3. Save time with online reviews
Motion waste occurs when people spend time physically moving about. For example, if a business analyst has to walk up a flight of stairs two or three times a day to see the business experts, this constitutes motion waste. There is also a strong correlation between motion waste and time wasted in extra processes. Another example: Team members can increase motion waste by attending meetings that are either not required or where their presence is required for only a short time. It's not just the time wasted but also that the person has to regain focus after the meeting, which creates waste from task-switching, too.
One approach in helping to reduce motion waste is to improve the visibility of project artifacts and improve the collaboration between team members and stakeholders. CLM does this by allowing all of the development artifacts of any kind to be linked together. These artifacts (and information about them) are then made available through web browser views for stakeholders and team members to see. They can then access almost everything from their desks, rather than going to many meetings to review artifacts and information. This reduces a lot of motion waste and improves collaboration between people in different locations.
Now, because all aspects of the project are available through a browser, it becomes possible to tailor dashboards to show the information that managers and stakeholders want to see. This, in turn, promotes business agility because the stakeholders can see the project status whenever they want to. It also reduces the waste of the team and team leaders as resources, because they can reduce time spent in meetings.
Figure 4. Show team progress in a web browser
Having this data available can reduce time spent in status meetings. On some projects, these have been reduced by half, because the team can focus just on the amber (caution) and red (alert) areas of the status report. It can feel a little uncomfortable initially, because the data is real! This can improve the quality of the decision making and means less time spent collecting data, because status updates are automated by CLM.
"Extra features" certainly sounds undesirable. Of course, if features do not provide value to the business, then developing them is wasteful. They might not even be used at all. Even more significant is the delay that they can cause to the functionality that offers the real value to the customer. Of course, more features implemented also means potential sources of more defects and more software to maintain after it is released.
So how do we make sure that we don't create extra features in the first place? There are several approaches that can aid in reducing extra features:
- Have a clear vision
- Actively involve a range of stakeholders early and often
- Move away from large text documents to visual representations, and use scenario-based requirements definitions (see Figure 5).
- Delay detailed specifications until the sprint of implementation
- Establishing a backlog of outline requirements to feed into an adaptive and iterative planning approach that implements the important requirements first.
We can't do justice to all of these ideas in this article, so please see the Resources section for links to more information. Most of these approaches do have one thing in common, though, in that they allow the focus to change from complying with a complete requirement specification to choosing to only deliver requirements that offer significant value to the business. In particular, the shorter cycle from requirements to delivery means that extra features are less likely to be implemented at all.
Figure 5. Visual scenarios aid understanding
CLM supports defining features in many forms from user stories or use cases, storyboards, UI sketches, process diagrams, text, images, and even audio or video. Not only can stakeholders find what's new and changed recently, they can also discover the wider context requirements in terms of links to both internal and external artifacts. For example, what do the screen mock-ups look like for this user story? In our experience, using a range of visual techniques improves success simply because this is easier for people to understand. It's clearer how it affects their daily work.
As discussed in the Motion section, having a single repository that can be seen by all relevant stakeholders online, with lots of mechanisms to make it easy to find content relevant to each individual (such as dashboards, tagging and filters), makes it easier for people to find and comment on what's' relevant to them. Having active involvement from a broad range of stakeholders early is invaluable, especially those from the business departments or clients, because they can provide feedback about how useful the functionality will really be.
Finally, huge benefits can be gained in CLM in that the features can be easily fed into agile development plans, which then allows the highest-priority features to be implemented first, thus delivering the most benefit to the business or client.
Overall, the transparency, collaboration, and context help us understand the features. That, in turn, improves the quality of decision making. The priority moves away from conforming to the specification toward validating the true value of the features with a broad range of stakeholders and then implementing the key features early.
Task switching and hand-offs are similar kinds of waste. An example of waste due to task switching is when a developer has partially completed coding one piece of functionality and then switches to another. The developer might have to waste time removing all the original code changes, before it's possible to starting work on the new functionality.
Many personal productivity books (such as Getting Things Done and Do It Tomorrow and Other Secrets of Time Management) emphasize that multitasking is not faster. If you have two jobs to do, it's quicker to do one and then the other, rather than try to do both at the same time. Agile development teams follow this tenet to minimize the number of stories being worked on at once.
In an ideal world, there would be limited task switching. The way in which people and other resources are managed can help minimize this waste. For example, not over-committing teams so that they are juggling too many different tasks can help. Also, undertaking projects in sequence rather than loading individuals or teams with many projects at once can alleviate some task switching.
However, if task switching is necessary, CLM can help. It's much easier to minimise the task switching waste in getting up to speed because all artifacts are linked and related (business processes, requirements, discussion forums, reviews, comments, tests, designs, code, plans, and the people involved). This gives them context, and it shortens the time necessary to switch from one task to another.
CLM provides excellent support for task switching, because all artifacts are stored in the CLM repository. First of all, we associate all file changes (whether they are to code, designs, or documents) to a task. Then we manage those changes as change sets. Finally, we allow the developer working on the task to suspend a set of changes (see Figure 6), which reverts all of the code to its state before the change was started. This means that developers can have many code changes running in parallel at once, with minimal effort required to start work on any individual task. Obviously, it's not ideal to work this way, but if you continually have to wait while some other artifact is available to edit, then this provides a way for you to minimize the waiting waste and also keep the waste associated with task switching to a minimum.
Figure 6. Save task switching time with suspended change sets
Hand-offs tend to introduce waste in a different way. In an ideal small agile project, you would have minimal hand-offs, because team members tend to take on all project roles (write stories, develop code, test, and so on). However on larger projects, or where you don't have multiskilled individuals, hand-offs become necessary. Hand-offs can introduce significant waste for several possible reasons: rekeying information between tools or teams, waiting waste because team members are unaware that something is ready, lack of sufficient detail, outdated artifacts, or a change has not been successfully communicated to the team.
CLM allows team members from any team to view information and follow changes in other teams through RSS, email lists, or viewlets in the web. (We realize that, for some projects or organizations, having access to everything is not appropriate, so CLM also provides other access control options.)
This means, for instance, that:
- Requirements teams can see which of their requirements have been turned into running, tested code (see Figure 7).
- Development teams can track new defects reported by the test team, as well as changing requirements, and easily plan work to implement new requirements and fix defects.
- Test teams can see which requirements have changed, which stories are ready for testing, which previously broken tests are now ready for retest and can easily plan testing activities.
Figure 7. Requirements status summary
By making this information visible and easily accessible, it can greatly reduce the time wasted in hand-offs, extra processes, and motion, because team members have the information that they require at their fingertips (see Figure 8). They have access to the information without having to disturb other team members for status updates.
Figure 8. Dashboards show immediate updates from other teams
Hand-off between projects and later phases
The previous section focused on how waste can be reduced within projects. This section focuses more on waste between projects, departments, and third parties. There are several common types of waste at this level:
- An application is transitioned to a support team with few of the development artifacts, such as requirements, designs and tests. This requires the support team to figure out how the application works before being able to provide satisfactory support.
- An application that has not been touched for a while needs to be upgraded, but the original requirements, design, tests, and sometimes even code can no longer be found.
- An application has certain non-functional requirements that have been solved elsewhere in the organization, but it is hard to find the other applications that have those requirements or, from there, to find the designs and code that were used to solve them.
Software asset management can help solve these kinds of problems and reduce waste related to not being able to find the right information at the right time. (An asset can be used to store any useful group of artifacts, their context, and metadata, such as code, test scripts, service definition, reference architectures, business models.) In particular, using IBM Rational Asset Manager can reduce the time that it takes to find existing assets by allowing people to use a mixture of formal categorization, tagging, and text searches. This approach makes it very quick to find high-quality assets and download them to a desktop or development environment for use.
By using IBM Rational Asset Manager as a definitive library for all of your software assets, you can start to directly tackle a lot of the waste and inefficiencies that occur in hand-offs at the project and program levels. It provides a single portal for all project documentation, code, and artifacts, so the support team can have access to all of the development information through this software. This makes it easy to quickly find development artifacts for systems in maintenance, and teams will be able to quickly identify other projects that have solved similar problems and reuse their solutions to save time.
Figure 9. Rational Asset Manager visual browse view
Partially done work is the amount of effort invested in features that are not yet implemented. Using the waterfall development approach leads to lots of partially done work, because a lot of time is spent upfront in elaborating requirements and in design. This results in no working software until very late in the cycle. This is the primary reason why teams and organizations move to an iterative approach, so that they can complete features quicker and potentially deploy them to start delivering value sooner.
Even if you are using an iterative approach, waste from partially done work is still important to consider. Within an iteration, if the focus is on completing each story or a limited set of stories in turn (or specific use case scenarios), with the team working on as few stories at one time as possible. This will limit partially done work and mean that some completed code will be delivered within the iteration or sprint. If the team's work is spread across all of the stories, then there is a danger that testing will be left until very late in the iteration cycle, and the team might not deliver any new functionality in that iteration, because the defects will be discovered late, and there might not be time to fix them.
CLM can help in a couple of ways:
- First, by using the agile planning taskboard from Rational CLM (see Figure 10), it is immediately obvious if there is a lot of partially done work.
Figure 10. Agile Planning taskboard showing partially done work
- Second, CLM can help teams have a greater number of developers working in the same area of code (this is required when trying to minimize partially done work). In this collaborative approach, each developer gets a sandbox. This means that code can be developed in isolation without disrupting others. However, it also provides a mechanism for developers to deliver to each other if required, so that they can build on each other's work without sharing with the whole team. This flexibility allows close collaboration in order to reduce the partially done work within a project.
Extra processes are additional processes that do not help in delivering value to the customer. For example: producing documents that no one reads, updating plans, manually collecting metrics and progress, organizing reviews that participants don't respond to, and such.
If the process does not provide value to the customer in some way, there is a risk that it is adding process without benefit. Worse still, if it delays time to value for the customer, it is also counterproductive.
So how can CLM help? CLM can be configured to enact an organization's process so that teams are guided through the process. Sometimes tooling makes it harder to follow a process, and thus increases waste. However, in this case, it means that following the process tends to be less burdensome and easier than not following the process. An example of CLM enacting a process could be a team implementing unit testing and deciding that they need 70% code coverage from their unit tests. CLM can prohibit code from being delivered if it doesn't meet this criterion.
CLM also gives teams the flexibility to overwrite the process if they want to work a certain way, or because they find that some elements of process aren't working for them. So in the example in the previous paragraph, a team could decide that they want a higher level of coverage for certain components or that they want to provide some flexibility on whether this rule is enforced.
As described in Extra features, CLM supports a way of defining requirements that focuses away from large documents and toward waiting to define features in detail until the iteration when they are implemented. It also supports writing customer tests as an alternative to detailed requirements definitions.
Finally, it's important that teams use their retrospectives to analyze their process and determine what could be changed to increase their productivity. CLM helps by collecting data across all tasks and then providing the capability to analyze this data to determine whether there are processes or tasks that aren't adding value. (See the section about Value chains and measuring waste, which follows.)
Defects cause two kinds of waste: the waste in repairing the defect and the waste caused by the software not working correctly. CLM helps reduce the creation of defects by improving the quality of requirements and also helps to reduce the time taken to resolve defects so that they cause as little waste as possible. The process of finding, fixing, and resolving defects is known as the defect value chain. It often has lots of waste, because it can require several teams or organizations to collaborate closely (the next section discusses how you can measure your own organization's value chains).
CLM supports lean software development by improving the efficiency of the defect value chain. This is important for agile teams, because they shouldn't claim story points with outstanding defects (meaning that the code isn't finished and is still counted as work in progress, which is very undesirable in lean software development), so it's critical that they can find and resolve defects quickly within a sprint. (Story points are the scrum unit of measurement for estimating complexity of user stories) In reality, it's important for all teams, because having an efficient defect resolution process is a key to ensuring that you don't build up technical debt during software development.
For example, at Toyota, people are coached not just to create a quick fix but to understand the root causes of problems so that the fixes can also prevent future weaknesses from building up. In their famous "Stop the Line" practice, when a defect is discovered, the whole production line can be stopped to fix it then and there. This is aimed at reducing additional work downstream. Applying that to software development, if the build breaks, every effort should be made to fix it quickly.
CLM helps by automating the hands-off between the different teams. This creates a significant improvement in the overall process efficiency by reducing time wasted during manual hand-off.
Figure 11. Defect workflow with Rational Quality Manager and Rational Team Concert
Using CLM, when the tester reports a defect, that information appears in the developer's IDE inbox of incoming work. Assuming that this is an important defect that can be fixed immediately, the developer can then suspend all current work in a single action, load in the baseline in which the defect is found, and work on fixing the defect. When the defect is fixed, the developer can resume the previous work, picking up exactly where he or she left off. After the code has been fixed and built, the tester is notified about which tests can be rerun, based on the fixes in the new build. This approach means that teams can resolve defects very quickly. In particular, waiting and task switching can be significantly reduced.
Let's look at a hypothetical example, one without and the other with tooling.
Figure 12. Manual defect fix cycle
In this hypothetical example, a defect takes 16.25 hours to fix, but 12 hours of time is waste (nearly 75% of the elapsed time), which significantly increases the time that it takes to fix defects. When this is scaled across the number of defects normally seen in a project, it can result in significant delays to fixing code and getting a working system delivered to the customer.
Now let's look at the same example, but using CLM to improve the collaboration.
Figure 13. Automated defect fix cycle with CLM
So in our hypothetical example using CLM, the effort to fix a defect is reduced from 4.75 hours to 3.25, and the waste is reduced from 12 hours to less than 2 hours. More importantly, it now takes only a little over half a day to fix a defect, which means that within a two-week sprint, it's possible to get very fast defect closure. This is critical to keeping the technical debt under control and producing high-quality software that is potentially deployable.
If the defect is not impeding progress, it could be argued that task-switching for each defect generates more waste due to intellectual restart time for developers. In these cases, defects could be dealt with in small batches and short cycles. Lean software development incorporates "temporary necessary waste" for just such situations.
Measuring waste and value chains
It's important to consider all of the preceding wastes in the context of the process and delivering value. Value chains are a technique to help teams and organizations develop an understanding of how long things take and how much waste there is.
Over the length of the value chain, it's possible to look at the total effort in proportion to the elapsed time to give an understanding of efficiency. In measuring a process, it's important to look at both total elapsed time and process efficiency. Some changes, such as automating a manual task, can reduce both efficiency and elapsed time, because they remove existing effort from the value chain.
Another way to think about this is:
Elapsed Time = Effort + Waste
Efficiency = Effort / Elapsed Time
Figure 14. Defect Value Chain example
In this hypothetical example, it takes 4.25 hours on average to fix a defect, but it takes 16.25 hours of elapsed time. So we recommend measuring two things: the amount of waste (elapsed time - effort) and the effort.
By concentrating on reducing the average waste and effort across a value chains (defect fix cycle, stories, or use case scenarios), you can start to make processes significantly leaner and provide more value, quicker, to your business or customer.
CLM can be configured to calculate the average waste and work at each stage of any work item (stories, defects, enhancement requests, use case scenarios, and such). This measurement means that it's possible to start improving your value chains with little overhead and makes this information very visible to teams, so that they can put changes in place to reduce the waste and effort in any particular value chain. The screen capture in the next figure is an example of a report from Rational CLM showing elapsed time, effort, waste, and efficiency for several defects. You can use this kind of report to measure your existing processes and identify where improvements need to be made.
Figure 15. Defect Efficiency Report
In this article, we have looked at various ways to notice and reduce waste with the aid of CLM, including these:
- CLM improves collaboration, especially across teams, geographies, roles, and different organizations. This can significantly reduce many kinds of waste. In particular, we looked at waiting, motion, and task switching and how CLM can help development teams, the business, IT, individuals, and outside parties all work together and interact more easily.
- CLM provides transparency and real-time dynamic planning and reporting. This lets us see more of the whole picture, look at problems more holistically, and take corrective action sooner. It can also help reduce the need for extra processes, reduce the need for motion, and help distributed teams be self-organizing. As discussed, CLM can also help reduce partially done work, extra features, and defects, plus provide new levels of communication among a broad range of stakeholders.
- CLM also makes improvements to automation. This article hasn't focused on this area because, on the whole, it doesn't directly map from lean software development to the seven types of wastes that this article discusses. But it's definitely worth recognizing, especially because this can help in implementing some very important practices, such as smaller, more frequent releases, continuous integration, and concurrent testing. These practices, too, can reduce waste, because they enable us to deliver more frequently and to get valuable feedback from the business. It's very important to understand any automation improvements in the context of the overall process. We discussed how to measure and analyze a process in the value chain section, as well as the potential pitfalls of looking at automation improvements alone or in isolation.
In summary, lean software development is a culture that provides a great wealth of expertise to improve software development. Respect for people and continuous improvement are keys to this culture. In this article, we have shown how CLM can complement the lean approach by enabling people to more easily see, remove, and ultimately prevent waste.
Many thanks to Anthony Kesterton and Tony Grout for reviewing this article and for their comments and support.
Learn
- Cited in this article or recommended by the authors:
- Lean Software Development: An Agile toolkit, by Tom and Mary Poppendieck, Addison Wesley (2003). ISBN: 0-321-15078-3
- Inside the Mind of Toyota: Management Principles for Enduring Growth, by Satoshi Hino. Productivity Press (2005). ISBN: 978-1563273001
- Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, by Craig Larmen and Bas Vodde, Addison-Wesley Professional; 1 edition (2008). ISBN: 978-0321636409
- Scaling Software Agility: Best Practices for Large Enterprises, by Dean Leffingwell. Addison-Wesley Professional (2007). ISBN: 978-0321458193
- Getting Things Done: How to Achieve Stress-Free Productivity, by David Allen. Piatkus Books (2002). ISBN-10: 9780749922641
- Do It Tomorrow and Other Secrets of Time Management, by Mark Forster. Hodder & Stoughton (2008). ISBN-10: 9780340909126
- Agile Requirements Best Practices, a blog by Scott Ambler.
- Explore the Jazz.net CLM page.
- Learn more about Collaborative Lifecycle Management (CLM), which provides integrations across Jazz-based applications, to connect the work of analysts with development and test teams. You can also watch a demo of the software integrated for CLM and keep up with CLM news on the Jazz.net site.
- Learn more about the software used in this approach:
- Rational Asset Manager
- Rational Quality Manager
- Rational Requirements Composer
- Rational Team Concert
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the "Getting Started" ones are free.
Get products and technologies
- Get the free Trial Download or check the Trials and Demos page for Rational software.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
Discuss
- Join the Rational software forums to ask questions and participate in discussions.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. You'll get worldwide exposure, RSS syndication, a byline and a bio, and the benefit of professional editing and production on the developerWorks Rational website.
- Follow Rational software on Facebook and Twitter (@ibmrational), and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Connect with others who share your interests by joining the developerWorks community and responding to the developer-driven blogs.
Paula White has been working in the software development field for more than 19 years. She has worked as an architect, software developer, trainer, mentor, practice and technical consultant. At IBM, she currently works both as a Rational brand architect and a technical specialist in Collaborative Lifecycle Management (CLM), architecture management, requirements, and asset management. Outside of work, she enjoys spending time with her young family, gardening, music, and cycling.
Steve lives in Twickenham, London, with his wife and young daughter. He has worked as a technical consultant for IBM Rational since 2000, where he is a certified scrum master specializing in agile project delivery, modeling, and patterns-based engineering. He has written several articles covering the latest features in Rational Software Architect 7.5 and 8, as well as articles discussing lean development and various extensions to Rational Software Architect, Rational RequisitePro, and Rational Team Concert. Outside of work, he enjoys spending time with his family and studying, teaching, and practicing Tai Chi.
