Tips and Tops on using the SAFe Business Agility Assessment

As a coach I help organizations to innovate by growing their capabilities to deliver valuable software in short lead times. I always start my assignment by assessing the situation and creating an overview on the challenges ahead. I like to use a maturity model to structure my findings and to make sure I don’t overlook aspects. With the results of it, I’m better equipped to direct efforts towards success. Every two months or so I will repeat the assessment to get an idea on progress and to support discussions with my client on what next actions best to take. In the past I’ve often used the scaled maturity model that was developed together with Dutch Tax Office. Recently I came across the renewed SAFe Business Agility Assessment and I believe it’s quite useful for organizations that use SAFe as their scaling model. Therefore I would like to give you an idea of what the SAFe Business Agility Assessment is, and give you my verdict on the suitability of it.

What does the SAFe Business Agility Assessment comprise

The assessment follows the structure that is defined in the SAFe framework. SAFe describes 7 “core competencies”. Each competence consists of a set of related practices around a certain process area. You can find descriptions of the core competences by navigating to the blue circles on the SAFe overview on the scaledagileframework.com website. There are competences focused on team “Team and Technical Agility”, focused on leadership: “Lean Agile Leadership”, focused on portfolio: “Lean Portfolio Management” and so on.

If you drill down to a core competency you will get a description of what practices it comprises. One of the competences is Agile Product Delivery which concerns the development of a solutions as a team of teams or a SAFe calls it: “Agile Release Train”. I will use this practice as an example.

Within the Agile Product Delivery competence several practices are described. For instance the role of Product Manager, System architect and RTE are described; the program increment and events on the program layer like the PI big-room planning are described, etc.. The practices on Agile Product Delivery support the first principle of the Agile Manifesto “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”:  

1.      ensuring customer centricity and the value of the solution delivered

2.      developing as one team in the same cadence and decouple deployment to production environment from releasing software to end-users

3.      improving the lead times from idea to deployment

Below you find a infographic that shows the core competence and it’s practices.

The assessment follows the setup in core competences and supporting practices. For each core competence there is an Excel tool to assess it. Within the tool there is a list of statements for the supporting practices. Each statement can be rated on a 5 scale value from fully true to fully false or set to not-applicable. I’ve taken some statements from the assessment:

·       We gather feedback from customers who use our solutions

·       We research customer experiences through Gemba

·       We define features with stated benefits

·       Prior to our planning event we write features with defined Acceptance Criteria

·       We support customers in adopting our solutions

·       We analyze how customers use our solution

For personnel working in software development most of the statements are not difficult to assess. Rating them is of course subjective and less straight forward. While rating, the Excel tool aggregates the ratings per practice on a scale from 1-5. As a result of the assessment you will find a radar chart; see the example below:

 

 

SAFe has created a toolkit for community members to support the preparation and the assessment itself. The toolkit contains a presentation to support an actual assessment workshop. It contains the Excel assessment sheets and a preparation checklist. Several videos are available that explain the way of working for the assessment for the workshop facilitator.   

Tips and tops on the assessment:

The SAFe Business Agility Assessment follows the structure of the SAFe framework and uses concepts and terminology that are well explained on the website and in SAFe trainings. For SPC’s there is a toolkit provided that will guide you through the assessment process and tooling. The overview by means of the radar charts give insight in improvement area’s and support transparency and continuous improvement.

The SAFe Business Agility Assessment is setup to be a self-assessment. However, it requires in depth knowledge about the Scaled Agile Framework as the structure and terminology is partly specific to the framework. For those new to the framework some of the statements will be difficult to comprehend.

For me personally I like to start with to get a course overview of the situation at a client. I often read over the individual statements of the assessments to verify whether I’ve covered all relevant items. However, I don’t rate each statement individually as it takes quite some time. I just simply overwrite the calculated values to get the radar charts and be able to communicate the first results and maybe decide which area to look deeper into.

Also when working with my client for a while, I like to get an idea of, and show the progress of my work. As the assessment tool is setup in Excel it is easy to grab the assessed values at a certain point in time and copy them as another series. Adding the series to the radar chart will give an idea on the growth, see the example below:

 

 

 

Another change that I’ve made is, it to adapt the Excel tool slightly, to be able to add a description for a rating. Rating the statements is subjective. Given you want to see if you’ve grown after last assessment it is quite handy to add a field to describe your reasoning for choosing a particular value.  

As a certified SAFe Program Consultant I’ve come to appreciate the SAFe framework. However, there are other scaling frameworks around like Spotify an Nexus. The maturity assessment that I’ve previously used was based on SAFe, but was more framework agnostic. As such it has proven useful for assessing maturity in assignments where the organization used one of the other models. Note that making the assessment more framework agnostic will make it less suitable for a self-assessment as the questions required more interpretation of the situation.

All in all I quite like the self-assessment tool provided by the SAFe framework. I will definitely use it again, the next time I’m working on a SAFe implementation. If you like to learn more or want me to guide you through an assessment, then don’t hesitate to contact me. Leave your thoughts below!

 

Guarding your software investement (Blueriq)

Organizations struggle to sustain the added value of custom developed software. After implementing a new piece of software, often new functionality is added to respond to the changing environment, regulations and user expectations. As a new functionality is added, the maintainability of the software often deteriorates. The reason for this is that some changes require a (slightly) different setup of the structure of the software, the architecture. Changing the architecture is often costly compared to the business value of one single added feature. There is a chance that someone decides to realise the feature without changing the architecture. When more similar features are requested over time, changing the architecture will become costly as more features have been added along the way. In such a scenario it is likely that at a point in time, adding features becomes too costly compared to the business value that the feature brings. The organization is left with a piece of software that doesn’t fully support the organization’s processes and is too costly to change and to replace. A new investment is needed to turn the ship around.

How much better would it be to guard your investment and constantly look at the maintainability of your systems to make sure at all times that the right amount of effort is going to keep software ready for change? But how do you do this? How do you even know that maintainability is becoming an issue?

There is no easy answer to these questions because creating maintainable software is a craftsmanship. It requires a structured way of thinking of software developers. It requires analytical skills to oversee the models. And when the software system is too big to oversee, it requires tooling to help assess the maintainability. It is this tooling, specifically for software developed with Blueriq that I want to bring to your attention.

I’m currently involved in developing software for a big governmental organisation. We are using a combination of tools to create the software solution. In this constellation Blueriq is used as the rule and form engine. For some solutions, the amount and size of models has grown over time. It becomes hard to oversee the models and find out where improvements can best be made. Having a tool that provides quality metrics about the models is key. Many software development tools therefore provide complexity and maintainability metrics out of the box. But as much as I like Blueriq for knowledge modeling, there is no support to check model quality. I was left on myself without metrics and even without much theoretical guidance on how to find complexity of the specific models used. I decided to dive deeper into the subject and I have created a tool that gives me insight in the maintainability of the software models in Blueriq.

I have used the tool to analyse not only the solution I’m working on, but also other solutions realized on the platform. It gave me insight about the complexity of the models. As a team we are now targeting the parts with highest complexity; we are refactoring the models with biggest problems to improve the maintainability. We have already successfully refactored several models which resulted in a reduced amount of issues found in the operational software. Moreover we’ve made sure that the architecture of the solution is more capable to cater upcoming changes that we are working on. We’ve been able to add a new range of features with an effort corresponding to the business value of those feature.

With this tool the organization can guard its investments made and make sure that quality of the models can be kept under control.

Do you have a team working on building solutions in Blueriq, or are you struggling to get quality under control? Would you like to have facts and figures about this software, rather than on someone’s gut feeling? I can give you the facts and figures about the maintainability of your models. I can help your team in finding the best opportunities for improvement and give guidance on how to actually improve the models or the structure of solution. Feel free to contact me and discuss the options.

The 4 things they don’t tell you when you become a Product Owner

Agile software development is seen as one of the big enablers for companies to keep in pace with their rapidly changing environment. Many organization however struggle to implement an Agile way of working. It requires a shift in the way of thinking of the people involved. A shift that is often easier made by IT departments then the Business. The key person in an Agile approach to represent the business is the Product Owner. The Product is part of the development team and gives direction and focus. If this Product Owner is not capable to fulfill his or her role, the benefits of Agile can’t be realized.

A recent survey conducted by TOTTA Research including 700 respondents in the Netherlands shows that only in around 20% of the organizations the product owner role is well institutionalized. The 80% others have no mandate or operate on behalf of the ones with mandate, see it as a side role, have multiple product owners or have an analyst perform the product owner role.

If we look at the Product Owner role (see the text box) it is easy to see that it is overloaded with responsibilities. Product ownership requires good understanding of the business and its clients. It requires mandate from user groups or the organization, it requires good motivation skills. Especially in larger more complex projects it is difficult to find this role to be performed by one person.

A closer look at the role and responsibilities of the product owner shows overlap with traditional roles as project manager, product manager, Business analyst and System analyst.

The characterization of these roles require  the product owner as Product Manager to be a creative thinker, to have vision, and to be people oriented. As a business analyst and system analyst, the Product Owner is structured in his approach and analytic. As a project manager the product is accurate to monitor the project and steer it from a financial perspective.

It is unlikely to find all these characteristics developed in one person in a level to be effective in larger and more complex projects. The question is how can we support Product Owners? 

I am currently conducting a survey to investigate the needs of Product Owners in the field. Please contact me if you would like to take part in this survey. I am very interested in any insights you would like to share. 

Smooth customer interaction using DEMO

We live in a world where customer experiences with your company is spread far and fast. The way your customers will value your company’s products is not only based on your products itself. It is for a great deal based on the way that you support your customer in his process of buying, returning or servicing your products. The support processes however are not always thought through and are often not well supported by IT systems.

To give you an example: in my town, garbage is collected in underground containers. In order to get access to these containers you need a key card. Some time ago I couldn’t find my key-card and after turning my home upside down and inside out I still couldn’t find it. I decided to order a new one through the municipalities website and paid for it; I was happy with this service. A few hours later however, the key card I’d been looking for, showed up in an unexpected place. I decided to cancel the order for the new key card. I looked for the option on the municipalities website, but it wasn’t there. I called the municipalities office and got helped nicely but it seemed there also was no option for them to withdraw the delivery of the new key card through their systems. The civil servant decided to just continue delivering the key card and refund the order amount. I got helped nicely, but it left me puzzled with the question why there is no support for such an obvious scenario. Why wasn’t it possible to cancel the order?

To formulate the question in a broader perspective: How can process analysts and IT personnel forget to implement some of the quite obvious customer scenarios?

I believe the answer lies in the fact that employees setting up the support procedures lack a good model on what scenario’s to support. The quality of support is then in the hand of the employees drafting the procedures. Techniques like the voice of the customer are helpful but may overlook situations. What if there was a model that they one could use to make sure all possibilities are thought through? What if they had a structured way of drafting support procedures?

The Design and Engineering Methodology for Organizations methodology (DEMO)  provides a model for this. The methodology is based on the theory of human cooperation and the research of consequences of it for organizations (research of Habemas, Austin, Searle, Bunge and Dietz) the DEMO methodology provides a pattern for a transaction as described in the example. It’s a scientifically based pattern but is easy to understand as it is common to all of us since we use it all the time.

Let me try to explain part of the model based on an the example I just used. Imagine the situation where there is no IT system to support the transaction between me and the civil servant. For simplicity I also take the payment out of the scenario. In this example I go to the municipality office to get a new key card:

1. I request: “Can I please have a key card as I lost the one I got initially?”
2. The civil servant promises: “If you live in our municipality I can give you a new key card”, he checks my passport and his registration and confirms that I live in the town.
3. The civil servant gets a key card (execute)
4. After coming back to the counter he states: “You can take this key card to open the underground container.
5. I accept the transaction by picking up the key card and thanking the civil servant for his swift service

There are 5 elementary steps in this transaction

DEMO gives a thorough definition of these steps of a transaction. Any transaction we engage in, in real life will follow these steps. Since the real life processes are the basis for IT systems support, we can benefit from this pattern.

Beside these 5 basic steps there are some other scenario’s possible that again are well defined in DEMO:

•        If I don’t live in the town, the civil servant can decline my request.
•        While the civil servant walks to get the key card  and I found the original one in my wallet, I can revoke my request.
•        if I see that the key card is one for a different type of container I could reject the it when it is on the counter.
•        If I get home and the key card doesn’t work as expected, I could also revoke the acceptance of the key card by going back to the counter and returning it.
•        And some more…

The full DEMO transaction pattern defines 15 activities like “request, decline, accept, revoke accept” and describes how we end up from one state into the other if we are for instance to revoke a promised fact. If we consider all the steps in the transaction pattern, it will helps us to create the proper support for our service teams and for our IT support. It prevents us from overlooking a scenario.

To my opinion, DEMO provides models that are very useful for anyone working in the field of business process management and the (IT) support of human centric business processes. It provides a basis for designing business process and designing the support for it. One of the models I described here makes us consider all steps in a transaction so we can make sure that all options are well supported. Not implementing a step could cause an overload on your service center having your agents to solve issues that could have been prevented by thinking through the process using the DEMO transaction pattern.

How Model Driven Development improves business agility

An interesting observation I’ve been able to make while working with Business Process Management Suites and other Rapid Application Development tools is on how developing software with these tools helps improving business agility. Everyone working in software development knows there is a big fuzz about Agile and Scrum to bring agility to the software development process. My experience is that in many cases the software development really benefits from these Agile approaches. However I believe that by using state-of-the art Model Driven Development (MDD) tooling, we can take this Agility a big step further, to the business itself.

TRADITIONAL SOFTWARE DEVELOPMENT If you look at traditional software development, you’ll find several disciplines working together to create software. In the picture below you can see how information is handed over from one discipline into the other.


Interesting to note from the picture is that most disciplines only create “paper” files. It is only the implementation discipline that is able to create an executable program from these paper representations of the software. The distance between the developers in the implementation discipline and the business has caused many problems in the past. To overcome these problems several measures were taken. One stream tried to make the software development process more formal and “make sure” that information from one discipline translated correctly to the work of another (RUP). Other streams tried to have developers take roles from several disciplines and work “in close collaboration with business” (Agile). Both solutions have their benefits and challenges.

MODEL DRIVEN DEVELOPMENT Model Driven Development takes the best out of both approaches, it allows for each discipline to take control of its own executable models and it allows the development team to work in close collaboration with the business. Using Model Driven Development every discipline can create executable software for the aspects they are working on, see the picture below:


To give you an example: The business modeling discipline will create an executable business process model. Now you may ask yourself, “but what to execute when many requirements are not clear yet?” “What can business users expect from an empty process model?”. At the moment of eliciting and specifying the business process there are no forms, interfaces yet and there is no data available! Definitely, it is not a complete solution that the business modeling discipline creates. However the business modeler defines the process steps and defines what department or what specific role handle the steps. He specifies the service level agreement (SLA) for a certain step and where to escalate to if the SLA is not met, etcetera. Having the exact business process model in place will give other disciplines a clear picture on where their work will fit in. When other disciplines have added their models the solution starts to work. At the end of the project the business process created in an early phase will still stand!

IMPROVED BUSINESS AGILITY So how does this way of working and these tools improve your business’ agility to adapt to changes in the market or other changes in your environment? I’ll describe three ways in which MDD helps bringing agility: the ability to give feedback quickly on required changes, the ability to change one business rule without affecting other aspects of the software and the ability to have business users change business rules themselves.
QUICK FEEDBACK By being able to show the result of models in real software gives the business possibilities to feedback on all of models based on software and not on paper representations of the software. Most Model Driven Development tools have the ability to unit test models and show results while developing (Agile)

SEPARATION OF CONCERNS Secondly the different models themselves treat different aspects of the delivered software, yet fit together like pieces of a puzzle. The fact that separate models exist for each aspect means that these models can also be changed independently. Suppose a process step is worked out as a wizard that guides a user through a set of dialogs. Then the actual information gathered may change without a change of who is filling out the form. The same way the process step may be routed to a different department, without the need to change the actual dialogs. The better you are able separate concerns and keep from mixing them, the better your solution will be adaptable to new situations and the higher your business agility will become.
RULE DELEGATION Thirdly we could actually delegate models to business users. For instance a decision table readily available as a model in the development suite could be changed on the fly by a business user to update a calculation or a decision in the system.

I would like to hear your thoughts about how MDD tools could bring agility to your business. Feel free to contact me if you would like to know more...

Using a Wiki to support Agile documentation

Currently one of the projects I’m working on is for a client in the public sector. I’m part of a team that creates specialised software to support the processes of this organization and all her partners involved in child protective services. Currently the software is being used by around 1500 personnel and this number is only expected to grow. This means that although we use an Agile way of working to develop the software, we have to create documentation for the maintenance team to maintain and if necessary further develop the application. We use a BPM suite to develop this software. As you can read from previous blog items for documentation purposes I strive to use the self explanatory models of the BPM suite as much as possible but although we can cover a great deal of the documentation need with the suite we’re using, we still have to create some extra documentation in another form than the models themselves.

More specific we document:

• User stories, to justify the need for a piece of functionality and to steer the project
• Acceptance criteria, as a test base and to give more functional detail to a piece of functionality
• System test scripts, to be able to check regression and to help document more technical decisions
• Service definition, to describe the functionality needed for interfaces to more technical parts and third party interfaces.

Using User Stories for documentation is not a straight forward process. I wonder whether the set of User Stories you use on your project, sufficiently describe the functionality of the system. I also wonder whether maintenance personnel, not initially part of the team are able to navigate the user stories and find information they need easily. In my opinion just creating a backlog does not do the trick as the set of User Stories is fairly unstructured. At the start of the project these user stories describe needed functionality and form a good basis for documentation. Later on in the project the user stories also start describing changes to the earlier functionality. If you need an overview of the functionality created you, need to read through all the user stories created about the subject.

To help with this problem, I’ve created a functional structure derived from the application. The user stories created are placed in the proper place in the structure. The structure itself comprises the processes, process tasks and lower level modules that make up the application. The names of the elements in the structure follow the names that users (and thus maintenance personnel also) find in the application (ubiquitous language). The development team links every User Story to it’s place in the structure. The result is that the User Stories can easily be found back by maintenance personnel. This enables the maintenance team, but also the development team and implementation team to retrieve the information put in the user stories and acceptance criteria. As for user stories, the structure can also be used for the system tests or any other documentation you feel is needed for maintenance.

You may ask yourself what tool is needed to create this structure? Requirements management tools are capable of doing so. The problem with these tools is that they come with a price and a learning curve. The question is, is there an inexpensive tool that is easy to learn and easy to use?  

I’ve been able to create just that: Using open source MediaWiki with CategoryTree plug-in my team is able to document the software on those parts that are not covered by the BPM suite models. Creating a sprint, adding User stories, placing these user stories in the right place of the skeleton is easy and straight forward. Navigating the structure by the maintenance team and others involved is easy and follows the structure of the application itself. Adding test scripts, storing test results and documenting service descriptions in the structure is as easy.

Working with a wiki adds to the agility of the team as it is light weight, flexible and does the job well. Working with a wiki is more easily accepted by Agile team members then more elaborate requirements tooling.  

What I’ve created is a structure for documenting software in an agile manner. I’ve created a help page with templates and guidelines on how to use this wiki. Please contact me if you’re want more information or want to get the wiki pages enabling this structure. I can help you and your team to implement this way of working, giving them a way to document for maintenance purposes.

Lean requirements in BPMS, an example

Having written quite some requirements documents and now working with current generation of BPM suites I’m seeing very interesting improvement area’s in the field of requirements. These improvement areas are supported and made possible by these powerful tools...

Hanging on to old requirements habits of specifying everything up-front and requiring sign-off of specifications before implementation, is not going to make us effective using these tools. Translating paper specifications to working software is difficult for developers, let alone for customers. As the sign-off this document becomes part of the contract, a customer will try to avoid any mistakes as he has to suffer from any rework later on. Special attention is given to getting “complete and correct” requirements … on paper...

What if we had a tool that enabled us to demonstrate  to our customers what we have in mind directly. How different, if we could create models that are readable by customers and need no extra translation by developers. How great, if we (and our maintenance teams) would always have the corresponding version of the requirements available when looking at some implementation artifact? Sounds like a beautiful future...

I'll tell you, the future has arrived when using state-of-the-art BPM suites. I would like to give you an example on how you can exploit certain features of a BPM suite to obtain a lean requirements approach.

Requirements are implementation - Be Lean!

I would like to show you how to support business processes using IBM WebSphere Lombardi. Suppose we have the following business process to handle a Buyers Purchase Order:
figure: IBM WebSphere Lombardi Process Model

The question is: What requirements artifacts do we need to describe this process sufficiently for stakeholders to understand what’s going on and for the development team to understand what to build?

Let’s start at the process model: Some stakeholders like to get an overview of the process and get exited about process models like the one shown above. They can get an overview of who is doing what and when. They get an idea of decision moments in the flow and by analysing actual information gathered from ran processes they can optimize the flows if needed. However these models don’t appeal to everyone’s imagination... Isn’t it so that especially end-users are less interested in the overview but more in the details; that they can best contribute in the requirements process if they see the end-results of a run process, when they see forms with actual information to be entered in the right sequence.

Wouldn’t it be great if we could cater both types of stakeholders?

...the good thing is, we can...

The process model shown above is the actual executable process model in Lombardi. There is no need for us requirements people to describe it anywhere else or to clarify it anywhere else. The model neatly shows who does what, when, by showing swim lanes, process steps and process flow respectively. The model speaks for itself and since process steps are well named it is clear for almost anybody in the domain to get a good idea of what is going on...

To cater the other type of users who get excited if they see actual forms where to enter information, IBM Lombardi allows us to run the process in demonstration mode, showing mock-ups of the forms (to be described later) and to let end-users test the flow of the process by entering values and selecting scenarios showing the successive actions that take place.

Brings us to what we do have to describe apart from what IBM lombardi gives us by implementing the solution. Probably we want to give an overview of the objectives to achieve using this process model and the details of the process steps. On the details of the process steps, lets take the human step to Submit a Purchase Order, in normal requirements practices we are used to writing a something like a Use Case describing the interaction of the User with the System: we would describe the data entered and the forms used, we would describe validation rules and business rules and we would describe supplementary specifications.

Using Lombardi we can take a lean approach to providing this information and only describe those assets we can’t model in the tool directly. Let’s see what we can specify in the tool apart from the process model already described above: Domain objects, User Interfaces, Business and Validation rules, Coarse steps of the UseCase.

Domain objects

With Lombardi we describe the domain objects and data to be used in the system. Often the implementation glues together information available in various legacy systems and standard applications. Some of the processing probably takes place in the legacy systems and glues together the various systems. Often information crosses departments making it important to have a mutual understanding on the meaning of each domain element and attribute. Terms like Shipping date can easily be interpreted or defined differently over departments: one department may define the shipping date being the date where the order is picked and the box is sealed, another department may define the shipping date as the date where the order actually leaves the plant. Using the descriptions of these attributes and using business rules we can clearly define what is meant with a shipping date.

IBM WebSphere Lombardi DomainModel

User Interface

BPM suites allow us to create mock-up’s of the user interfaces or the actual user interfaces used in the system itself. The mock-up’s may not contain all details in the requirements phase, but because we can show this mock-up in it’s place in the process, we have a very effective way to communicate our ideas about the process and user interfaces. In the run down of the process the user can enter data and see if the flow of forms is correct.

IBM WebSphere Lombardi User Interface

Business Rules

Also the business rules we can describe directly in the BPM suite in a readable format. see for instance the decision table below. The headers above the table refer to classes and attributes in the domain model we have created or that we update on the fly. For us requirements people it is easy to create an executable model and have the user enter data in a form, for instance the values for updatedQuantityPercent and updateUnitPricePercent. The decision table can be used in various places: in the process flow to decide on the next step or it can be used to show or hide information in a form and so on...

IBM WebSphere Lombardi validation rule

Coarse Use Case steps

We sometimes only scratch the surface by providing and creating the models described above. Besides specifying the user's interaction with the system we often have to describe how to connect to legacy systems or how a certain task breaks down in lower level activities. We can break down the functionality in smaller steps to give more detail about the processing. Often these descriptions are sufficiently describing what is needed from a functional level. If more description is needed then describe each by specifying what the user wants to acheive with this step. Also by having these models in the tool we can easily demonstrate the working of the application to the user. Do we still need a detailed description of the workflow of the user interaction? Maybe yes...

But probably no, since we can model further details in a service:
IBM WebSphere Lombardi service

Using good naming we can put extra detail to communicate with users and for the implementation team to implement these interactions in the right order.

http://www.ibm.com/developerworks/websphere/library/techarticles/1101_wang/1101_wang.html

One of the issues with this way of using the actual models as a description of the functionality is that we have to be cautious not to stick too much detail to the first level of these models. Take the service... When detailing this service developer likely add more steps if necessary. If there is too little focus on structure we may end-up with unreadable and unmaintainable models.. be aware...

By doing so our requirements process creates the actual models and gives us the power to demonstrate the implications of choices directly getting feedback from users on actual implementation rather than on paper representation of the implementation.
I would say, no time to sit back... no time to hang on to old habits...

There are now new ways to serve our customer with way more output! Take control... add new habits, start working in an agile fashion use a lean requirements approach!
Start empowering your end-users!