Lean PPM – step 12: Documentation consumer type 2: project leads, business analysts, (requirements and software) engineers, or likewise folks

Prolbares (= project leads, business analyst and requirements engineers) express a lot more needs in documentation. Prolbares are around on all abstraction levels of requirements (see the requirements abstraction model RAM by Tony Gorschek and Claas Wohlin). Prolbares work from business goals, high level business processes down to tiny technical details. Prolbares are involved in the full lifecycle of designing and implementing desired changes (see “The life cycle of an initiative”). In the design process of a change they are responsible to elicitate, design, communicate, consolidate and confirm requirements of a change. In this context “change” is anything from a small continuous improvement in an existing system to a discontinuous innovation in form of a new product or service.

In respect if documentation, Prolbares are like chameleons. Some like to write novels, some hate writing any documentation, some like modeling, some prefer to paint pictures; some are more user experience oriented, some rather are technicians; some feel comfortable on the abstract levels of requirements like business goals, processes and features, some love tiny details…

Naturally the requirements of Prolbares for documentation are magnifold:

• In the initial part of the lifecycle of a change they have an interest about the current situation. Source code and acceptance tests are a good source of the current state of a piece of software – but unluckily, as mentioned in my last blog – this is often only part of the truth. Manual and organizational procedures do not have a source code. Documentation could be treated as the source code of a manual and organizational procedure.
• Prolbares consume and create many artifacts and share these with her team(s) like meeting notes, requirements specifications, prototypes, decisions, technical description, whatever is needed in the refinement of intiatives, epics and user stories.  Most of this is waste when the change is done. Most of it, but not all. Some pieces out of this huge amount of information is valuable for the first step – to remind on the current situation any time in the future when the next change is in the road.
• Because of the chameleon alike nature, finding anything that suits all Prolbares is like finding the holy grail. So we had to find options that satisfy the majority of the Prolbares.

Prolbares are hard to place within an organization. Reason is that Prolbares typically are not full time members in any team. If integrated into the IT organization (i.e. Scrum teams) they spent 50% of their time with stakeholders and business. If integrated into business, they spent 50% of their time with IT, and – if not – they loose contact to IT, what results in defects in the quality of requirements (conversation, confirmation, feedback loops). At digitec Galaxus business analysts are our Product Owners in the Scrum teams. 

If Prolbares act positive in an organization, they care for the whole (optimizing the system and not preferring a specific department). They act as mediator, moderator, translator between business and IT to balance needs and wishes. They support ideas to become visible; mature ideas into change projects and finally towards real implemented (continuous or discontinuous) innovations together with all involved departments, subject matter experts, external partners, management and whoever has stakes in the change.

This is the reason Prolbares typically have an interest on a higher amount of documentation than all other involved persons and job profiles in an organization. A good Prolbare want to understand the problem under discussion herself. So the write a part of the documentation for themselves. Then they use documented requirements to solve different views and conflicts between stakeholders in the design phase of a change project. Additional they try to create a documentation that best suites all stakeholder in documentation (from executive managers to engineers and technical experts). 

Unluckily often the documentation policies, structures and tools in an organization are not defined in a way to support Prolbares to ease their job. The results we encounter in many organizations. To many documentation; documentation that does not satisfy the needs of consumers; documentation that does not allow to search and find the requested piece of information to successfully work on a piece of work.

In my personal perception to identify an appropriate structure and tool support for this relevant part of documentation is the most critical point. In fact this is the part to support the activities of business analysis, requirements engineering and design in respect of the creation of required documentation. 

Lean PPM – step 11: Documentation consumer type 1: executive managers

Executive managers do not have a lot of time.  They are keen people…

I am sorry to break your flow of reading at this point for a short discussion about executive managers, middle management and systems that doom people to stagnation.

---Discussion about executive managers and locking systems

In my experience over the last 30 years, in most cases executive managers are really excellent people. “Indifferent” managers are mainly locked in the middle management – but not because the individuals are inaptly. Rather middle management is doomed by the system to work in an indifferent way. To change the system, I personally see under the responsibility of executive management. This is where I set my question mark. Maybe executive managers are doomed by the system as well. I encounter a real difference whether executive managers or owners are in the driver seat of an organization. Maybe managers better fulfil quarterly financial reports to satisfy shareholders. I personally encounter that shareholder profit in owner driven organizations is not that high as in manager driven ones, but in the long-term these organizations are more robust, show a sustainable growth, more creativity and innovation and you find a higher ratio of intrinsic motivates employees.

---End of discussion - back to the documentation thread

Executive managers read one page. Executive managers want to see things to progress or the reason why things get stuck. Executive managers take decisions and have an interest to receive appropriate information to take a decision. Executive managers have an interest to reach goals; in the big picture; in the change roadmap; in the alignment of the change roadmap with strategy; in financial factors. Executive managers lose interest very fast if they feel wasting their time. Sometime executive managers have an interest on tiny details – but in this case no documentation helps. In this case an executive manager best is informed face by face by a competent person.

So the requirements of executive managers regarding documentation are:

• Easy to find – best presented in a personal and (automatically) daily used dashboard.
• One Page information (scrolling is waste of time and inadequate).
• Executive managers pull information - except something might fail. In this case an executive manager expects a push about a potential failure so that she can take preventive actions.
• Executive managers do not like unpredictable negative incidents. 
• For sure executive manager like unpredictable success messages.
• As a subject matter experts: You can be sure that an executive manager has never read the detailed report about risks or delays until the issues bubbles up because of some accident
• Executive managers want to see the name of the competent person behind a project/issue/action in case she requires a face2face to receive tiny details (in case of an accident)

There is on important fact to remind: Executive managers typically are no team members. They represent the culture and visionary capital of the organization and own the additional responsibility of a catalyst: if a catalyst works well, the organization works clean and powerful; if a catalyst fails, the organizations state of health drops. Because of this face2face information is far more important as documentation. Documentation rather is used as form of reporting to detect devations from the expected path. The real communication for steering should be done personally in 1:1 or other forms of direct communication. It is a matter of interpretation, shared knowledge and trust.

At least this is my experience aligned with the following principle in the agile manifesto: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. And the head of the development team of a company is the executive management.

Lean PPM – step 10: Consumers of documentation and their needs

In my last blog I pointed out why there is a need for documentation. What we at digitec Galaxus figured out during the last year working with our Lean PPM system was:

• Who concrete are the target reader of a type of information
• What abstraction level and format does a target reader prefer to use
• What tools and environment does a target reader prefer to use
• What tools and elements do we already use in our Lean PPM that offer options for documentation

Based in these findings we now agreed to establish some rules how we want to deal with the topic documentation. I guess in many organizations the situation is similar, so hopefully my blogs about documentation are useful.

At this point I have to say this is nothing new about documentation in any way. Already before agile and lean these findings were well known. The very basic concepts of documentation are:

• Create a documentation only if there is a consumer that gets value out it
• The documentation must meet the needs of a consumer in respect of amount and abstraction level of information, the format and the tool to use
• If a user searches an information within the documentation, the documentation must support a structure and search so that the consumer will find the information easy and fast.

Sources that address these basic concepts are for example the International Requirements Engineering Board IREB e.V. in its foundation certification, the International Institute for Business Analysis IIBA with its BaBOK, or the differentiation between a product repository and a project repository as recommended by the International Software Product Association ISPMA.

Instead of listening to the needs and requirements of the human sources and sinks of documentation many organizations instead go primarily for standardization and the satisfaction of compliance constraints. From my experience organization should care to develop good documentation practices for the workforce with first priority and with second priority to be compliant to external constraints. In my experience it is always possible to transfer a documentation that follows good documentation practices into a format that as well satisfies external compliance constraints.

Funny that so many organizations and companies disregard the basic concepts as listed above. From my experience the overwhelming compulsion to create standards and satisfy compliance constraints outreaches the objective consideration that an unbalanced harmonization ends up in more drawbacks than benefits. Especially the demonic one-fits-all thinking that still creeps through the management floors – as well in respect of documentation…

A year before today we created documentation at digitec Galaxus following good practices only partially. We used epics and user stories in software development, we tried to avoid exhausting documentation in the requirements and design phase – but we did not follow good practices that support all types of consumers of our documentation. In the last year while establishing our Lean PPM, we discovered basically three different types of consumers. I use the terminology of digitec Galaxus as described my blogs “The value stream of the digitec lean portfolio Kanban system”, “The life cycle of an initiative” and “about project leads and business analysts...”. There is one blog dedicated to every consumer type. 

Lean PPM step 6: more details on the demand

My last blog discussed the demand capacity game on a coarse grained level based on initiatives in our Kanban board. Initiatives with clear business goals are decomposed ongoing by the teams into epics and backlog items and implemented by the teams.

Pure organizational epics (without software development) are implemented by the functional departments, software is developed by the Scrum teams and all these activities within an initiative are coordinated by a person in the role of a project lead.

That reminds me to write an additional blog about the difference between a business analyst role and a project lead role – and the difference of the position of a business analyst and the position of a project lead; and for sure why we still use the role project lead. These differences and options of misunderstanding lead to many discussion at Digitec Galaxus – and in other companies as well. One reason for this is that an agile company does not know the position of a project lead. We established this position for some reason – but let’s wait until I write this blog.

But back to the demand capacity game. So far it looks like the Scrum teams work only on stories that result in decomposition of initiatives into epics and stories. We at Digitec Galaxus discovered at once that this does not work – at least for us. There is additional demand coming into the Scrum teams. One type of demand is fixing show stopper bugs at once. Another type of demand are small enhancements in any of our software systems requested by functional departments that would increase productivity fast with small effort. An example is the change of a default value in a dropdown, so our users save two clicks several hundreds of time a day. Using initiatives for this type of demand would be the hell of bureaucracy.

So demand flowing into engineering has additional input queues beside the queues represented by the initiative Kanban board. We discussed this and experimented a bit with a very simple solution addressing the input queues for work into engineering. The decision may sound scary for classical management, but luckily our management agreed to experiment. With some small correction the solution works good and found high overall acceptance in the functional departments, in engineering and by the executive management.

The solution is as simple as this: From 100% capacity of the engineering team, 60% are invested into initiatives, 20% are invested into fastlane items coming from functional departments and (!) 20% of the capacity is slack time.

Some explanations to these input queues:

• The demand coming from initiatives is explained in my previous blog Lean PPM step 5: The demand – capacity game at Digitec /Galaxus. So read this blog to understand the mechanism.
• Fastlane is an interesting mechanism to open functional departments a very lightweight, well defined but clearly throttled queue into engineering. All departments have the right to move items in this one queue. I will discuss the constraints on this queue in the following.
• The most interesting mechanism: Slack time. Engineering decides completely autonomous about slack time consumption – with the one and only restriction: Show stopper bugs have to be fixed in slack time. This is a very keen mechanism to minimize the number of show stopper bugs. Show stopper bugs reduce the free slack time of engineering.

Let’s dive a little bit deeper into the fastlane and the slack time mechanism. First I present the fastlane queue.

I mentioned the fastlane mechanism already in my blog “The life cycle of an initiative – step 4”. Every functional department in our company owns a Kanban board to manage and work on their ideas. Everything that can be done within the department itself moves on this board from status “new” over “in progress” to “done”. The large things turn into initiatives and move to the status “idea approval required” to receive an OK or a declined from the innovation board. And there is a status we called “for engineering”. This lane represents the fastlane. In case the department encounters that an idea requires engineering to implement a small change, this item is moved into the “for engineering” fastlane. The fastlane for sure is prioritized as well. The most important small changes are on top.

As every department owns its own fastlane, you can clearly see a new problem: All fastlane issues from all departments compete for the 20% fastlane capacity of engineering. The question is: which issue to take from which department?! As we have seven departments, at every time seven issues are of top priority. We solved this problem as many problems should be solved: by a. a positive communication and b. by a clear assignment for a decision in case the positive communication does not end in a solution within a limited period of time. The communication partners are the subject matter experts of the departments (there is a subject matter expert in every department) together with the business analysts. The decision is assigned to the business analysts. In case the business analysts are not able to find an agreement (what did not happen so far) the head of business analysis takes the final decision.

In average we encounter that our Scrum teams are able to implement about eight to ten fastlane issues per sprint. So actually nobody has a real reason to be unhappy. On the other hand the positive communication between subject matter experts and business analysts creates a transparency about the needs of the departments. This results in a mutual understanding of the needs of departments. And yes, once – what a positive surprise – a department said “well we see, our need is not that important. It is obvious if we implement the need of the accounting first. That will end in a larger benefit for all of us”.

Interesting is for sure the discussion about slack time. Read my next blog for dis discussion.

Lean PPM step 5: The demand – capacity game at Digitec /Galaxus

In this blog I talk about the challenging task of the demand – capacity balance in PPM, or the problem of who works on what and do we have the required and capable staff members available at the right point in time. This is an omnipresent problem. We never have the perfect capacity to satisfy the current demand. So we have either too many resources or a bottleneck anywhere in our organization.

In classical PPM the balance is addressed by breaking down the work to resource level (work breakdown structure) in a first step and then – based on an effort estimation – the assignment of work to resources. The uncertainty that corrupts upfront planning are estimations based on assumptions instead of historical data and the effect of risks that materialize in the course of the projects.

The lean and agile PPM approach is not to break down all (!) the work right from beginning, i.e. avoiding big upfront decompositions and specification. Instead decomposition is done ongoing, so that at every point in time there are work packages that can be pulled by resources while work in the mid-term future may be still remind on a coarse grained level of specification. The PPM process cares for that at every time there are enough work packages available so that all resources can pull an appropriate package for further decomposition or implementation. The feedback about the speed the work packages are driven to the desired outcome (done criteria) is collected as historical data for estimation for the yet undone work packages. This leads to more reliable estimations, followed by a higher probability about milestones. As well changes imply less impact. Reason is that the ongoing decomposition of larger work packages into smaller work packages allows as well an ongoing adaption of the solution space to the changes in the problem space based on current findings and feedback. As side effect less effort is invested into upfront specifications that require rework in case of changes and materialized risks.

The core problem that demand and capacity never match perfectly is the same in a lean and agile approach. The core improvements of the lean and agile PPM compared to the classical PPM are more reliable estimations, the ongoing adaption based on fast feedback and less rework in obsolete upfront specification. As very positive side effect the feedback loops establish a better understanding and alignment to the strategy (if there is any ;-) The fundamental change is the switch from a classical push system (work packages are pushed to resources) to a pull system (resources pull work packages) together with feedback loops.

At Digitec / Galaxus we follow the lean and agile approach. But how does that work in reality? What are the “resources” we talk about and what is a “work package” that a “resource” pulls? Lets see how theory is put into practice.

1. The functional departments like product management, marketing or logistics. The core responsibility of these departments is to run our business, to be operative and productive. But additional these departments are responsible to improve and develop themselves either to implement the company strategy or to increase productivity. This is where the demand emerges. This is as well a conflict for the departments because any effort invested into specification (of the demand) reduces the capacity required to run the business. It is the responsibility of the top management to set goals and staff the departments in a way that they can deal positively with this conflict and have enough capacity to satisfy the specification part of their own demand. This is a serious topic – but out of scope of this blog. Many companies fail exactly here. 
2. The engineering and infrastructure teams. In my personal view these are the scrum and techniques teams. These are the experts responsible to develop and run the system(s) that automate and support the business processes on customer side and within the departments. This includes subject matter experts in the departments as well as business analysts or requirements engineers that – at least in my recommendation – are part of the scrum teams. These teams always are a bottleneck – at least in a dynamic and innovative company. Reason is that a dynamic and innovative company has multiple more ideas (creating demand) than by economic constraints limited investment power. So these teams are typically seen as the capacity side of the company, disregarding that these teams create as well demand to improve and refactor the system itself. Again, it is a responsibility of top management to set goals and staff the teams appropriate. 
3. The “product” or “program” management team. This a bit a special team. Partially it is a virtual team. It is neither demand nor capacity. It is neutral. The responsibility of this team is an optimize-the-whole mindset, a neutral position between demand and capacity. At Digitec / Galaxus the heart of this team is the Business Development team. This is a real team (not a virtual), an organizational unit of individuals with the job description project manager. In my point of view the complete (virtual) team has additional members: the top management responsible to define and communicate the strategy; stakeholder from departments and from engineering requesting their demand and by giving feedback about their current capacity situation.

From my point of view a project or program management holding a neutral position between the demand side, capacity side and the strategy side is a success factor for a company. Beside the responsibility to implement the strategy of the company by executing the projects, the core success factor is to find the right balance for every single project. This is done by organizational implemented feedback loops between the stakeholders of the demand side, the capacity side and the strategy definition organ. My team, the Business Development team at Digitec / Galaxus feels responsible as guards of a healthy organism that develops in a sustainable path towards the agreed vision.

At  Digitec / Galaxus the demand comes from the departments using the innovation process in form of initiatives. This maturing process of an idea to initiative is supported and guided by a project manager. The project manager starts to work with the stakeholders from the department(s) and with engineering as soon as a department proposes an initiative to the innovation board (see: The life cycle of an initiative – step 4). The responsibility of a project manager is to drive an initiative from idea to closure through the life cycle within the right balance between demand and capacity and aligned to the strategy. The alignment to strategy includes prioritization responsibility where the business development team proposes to the innovation board and reflects the decisions of the board back into the development teams and departments.

The organizational implemented feedback loops are 

• The monthly innovation board meeting itself. Goal of this meeting is 1. closing the feedback loop between top management all others about the progress and potential risks and existing impediments and 2. prioritization of the initiatives for the next round based on feedback from departments and engineering and 3. rating of new ideas coming from departments.
• A weekly standup meeting of the business development team to identify conflicts in the demand-capacity-strategy alignment game so these conflicts can be addressed in a next step. 
• The bi-weekly Scrum meetings in the engineering teams 
• A bi-weekly program level backlog refinement meeting where business analyst discuss the upcoming sprints on a cross-team level.

The most interesting meeting (scrum terminology: event) is the innovation board meeting.

The core responsibility of the innovation board meeting is the management of the initiatives Kanban board. This board corresponds with the Kanban board idea in the scaled agile framework managing the business and architectural epics. In the innovation board meeting we discuss the progress of our initiatives, collect feedback, draw out decisions about movements and priorities of initiatives. Input of this meeting is the feedback of departments and engineering about the currents status, existing risks and impediments, changes compared to the last meeting and proposal for the next round. The company strategy is omnipresent to the members in this meeting. The capacity – demand balance is addressed only in case of concrete conflicts or in case an initiative gets into discussion because of any impediments. The time an initiative rests in a specific status on its way through the Kanban board is influenced by the position in the Kanban board. An initiative on top of a lane (high priority) gets more capacity then an initiative below. To carry this out is completely under control of the teams working on this initiative. The board gets the feedback about the progress made and iff there are impediments or decisions to take. As the Kanban lanes do have a WIP limit (currently 16 for the “approved” and “in progress” lane) a new initiative can be moved to the next status only in case a free slot is available. The members of the innovation board meeting do have a transparent view how the teams plan their capacity by looking into the epic and scrum boards of the teams.

My team, the neutral Business Development team representing the PPM care within our weekly standup meeting about the feedback from all stakeholders about progress, conflicts and impediments of any kind. The proceeding of our meeting is pretty close to a daily scrum. As things change slower on initiative level then on story level, a weekly standup is sufficient to close the feedback loop. The two meetings before and after the innovation board meeting do have a special agenda. The pre-innovation board meeting agrees about feedback and proposals for the innovation board including new ideas coming from departments. The post-innovation board meeting works with decisions taken and identifies future measures to execute the decisions in PPM.

This setup of meetings in PPM basically works fine. Nevertheless we identified some flaws in the current setup we will address in the near future. The identified flaws are:

• The monthly rhythm of the innovation board meeting is very fast. This fast rhythm stresses the departments. Every four weeks changes in prioritization may happen and decisions about ideas are taken. That is a fast rhythm for departments. We think about to experiment with a six week period. The drawback of a six week period is a loss in flexibility and feedback. An experiment will evaluate benefits against drawbacks. 
• The bi-weekly program level backlog refinement period is too short. This meeting does not add that much value to the team backlog refinement as it 1. covers the identical time horizon and 2. Is a business analyst meeting only with lack of feedback from departments and stakeholders. We think about to align this meeting as follow up to the innovation board meeting. Additional we plan to invite stakeholders from departments and engineering as well to close a direct feedback loop working with the strategic decisions taken by the innovation board. This meeting corresponds in some kind with the release planning meeting idea in the scaled agile framework (SAFe). The difference is that we do not prepare a release. The agenda of the meeting is similar to the SAFe idea. Different is the frequency of one month instead of three months in SAFe and the duration of half a day instead of two days.
• The direct feedback about required capacity from departments in the initiative is distributed over too many individuals. No direct feedback loop between these individuals exists. The work on initiatives requires capacity from departments. We face situations where several initiative consume capacity in departments in parallel. This leads to conflicts if more effort and involvement is required as estimated. For sure we get the feedback and we prefer to invest into the high priority initiative first, but the feedback loop is indirect going over the project managers driving the initiatives. If the project managers do not share this information, capacity conflicts may escalate. We plan to address this as well with the redefinition of our bi-weekly program level backlog refinement. The new setup shall close a direct feedback loop through all involved teams.

Currently we are living a sub-optimal solution to visualize a capacity usage over all teams (departments, Business Development and engineering): My team established and maintains an Excel worksheet forecasting capacity consumption on key person and team level (from an initiative point of view) based on the feedback from teams and individuals. Yes, establishing an Excel worksheet is typically the sign for a sub-optimal local solution and an existing impediment. So this Excel is a strong hint to improve the process for capacity feedback from departments. This is one very important reason for the refactoring of the bi-weekly program level backlog refinement meeting. We are convinced that an improved program level backlog refinement meeting will close the feedback loop about capacity consumption far more efficient than any Excel worksheet or any resource management software.

While this blog discusses our demand – capacity game more on a high-level view, my next blog will dive deeper into the capacity game on program and team level, especially in engineering.

Building up a portfolio management Kanban system – step 1

My blog “Herdingants – so many opportunities, where to start?” listed some of the “post migration” main problems Digitec Galaxus currently is facing. The need to prioritize the work aligned to strategic goals but still preserve the agile and flexible way of dealing with changes was given.

The problem of us was that our backlog contains far too many items. I counted over 1200 items on different abstraction and maturity levels, sizes and of different types (bugs, features, ideas, …). The overview got lost and with this the chance to select and prioritize.

Working on a white wall with sticky notes and a technique like story mapping was not establish in our company. So applying Jeff Patton’s story mapping technique for clustering, selecting the important stories, identifying a walking skeleton and getting rid of deprecated stories just was not possible. Working with white walls besides feeding a sprint was unknown at all. Teaching and coaching this is interesting and valuable. Unluckily that takes some time until the teams are enabled to apply this and produce an outcome. I put this technique into my backlog and moved it a bit down. We needed an approach that produced faster outcome.

Well, that sounds like some kind of implementation of an agile framework might fit, addressing the needs of a larger organization. I personally know and expertimented with elements out of the frameworks and approaches 

1. SAFe by Dean Leffingwell, 
2. LESS by Craig Larman, 
3. Evidence-Based Management for Software Organizations (previous called Agility Path). 
4. DAD by Scott Ambler. 

With the consulting mindset of my previous work the temptation was high to go for one of these framework and to implement it in some adoption following my intentions. I had a grass play area. Well - I decided different.

I reminded myself on the approach: create a vision about a direction to improve and apply a series of small experiments to move towards the vision. First step in this approach is to create a common vision. To do so you first need to know about the different visions that are around in the minds of the different people. I started with a workshop about “agile portfolio management” with a set of involved persons like the team lead for business analysis, the head of engineering, one of the CEO’s and some team members that already work on a first concept of a portfolio management and innovation process.

Of course the attendees of the workshop expected my again to present a ready-to-go solution that fits for us. I started presenting SAFe with the background not to implement SAFe as it is. I used the SAFe picture to present a potential vision and to point at some important mechanisms and techniques relevant for organizing things in an agile way for a larger organization. This started a positive discussion what the requirements and constraints of the different stakeholders in this room were. We were able to create a common vision and picture as following:

• We need to manage items on a higher abstraction level then user stories used in the product backlog of (software) engineering.
• Such an item (a project?) aligns to strategy and shall deliver an outcome that creates business value.
• We need to re-prioritize items fast in case of external events.
• No item shall block our system so that other items have to wait.
• We want to follow the lean idea to limit the number of items we work on in parallel. So to say we introduce a work in progress (WIP) limit for the items in progress.
• We want to manage all types of work in this system: work that ends up in implementation of software, conceptual work (for example a new concept to organize a core process), organizational work (for example re-organizations), and combinations of these work types.
• We need a transparency for everybody in Digitec Galaxus. As we are distributed over several location (logistics, retail shops, headquarter) a tool support is required. As we already use Atlassian Jira, it would be wise to go for a Jira implementation of whatever we do.
• We need to offer the departments the chance to implement tiny software related changes and improvements in a fast way.

The SAFe image for sure influenced. The idea to use three abstraction levels of requirements and a Kanban system around the highest abstraction level was convincing. So we agreed about the first experiment: Beside the two already as default in Jira built-in abstraction levels of user story and epic we create a third and more abstract issue type we called initiative.

That was a start - no we had the tasks to work different from tomorrow on.

Hiking in Switzerland for hikers with knees symptoms

There are many among us, who are sportive and like hiking in the mountains, but are somewhat disabled because of having knee symptoms.

A good solution is to walk uphill and skip the downhill part of the hike. I tell you: Switzerland is the way to go. There are many cablecars and trains going up (and down) all the mountains here. With some good ideas there are many options of hard hikes without the need to go downhill. Since I relocated to Switzerland many of my friends asked for tours like this.

Following are some proposals. The tours are for sportive people who are able to hike for 3 to 5 hours and are able to go uphill several hundered meters altitude. The tours are selected in a way that you skip the downhill. That saves your bones. But: the tours are not for untrained people or beginners.

I would like to give you GPS tracks, cards, links an all other stuff right here. Unluckily my time is limited. If you really are interested call my up in skype (rainergrau) or sent me an email asking for more information to "rainer dot grau at zuehlke dot com".

Walensee hike, 3h hiking, 4.5h on tour

• take the car to Murg at the border of the Walensee
• park at the railway station
• take to boat crossing the lake to Quinten
• hike along the lake and then up to Walenstadtberg
• take the bus to go down to Walenstadt
• take the train back to Murg

View to Walensee hiking between Quinten and Walenstadtberg

Fronalpstock hike, 3h hike, 5h on tour

• take the car via Schwyz and go on for about 4km direction Muothatal (not Ibergeregg and not Brunnen)
• there is a rack railway station called "Stoos", park there and take the train up to Stoos, a small village half way up to the top of the mountains
• Start the hike from Stoos up to the peak called Chlingenstock
• hike along the rim from peak to peak to the last one in that row called Fronalpstock
• take the cable car down to Stoos from Fronalpstock and then the rack railway back to the car

View from Fronalpstock down to Lake Vierwaldstätter and Brunnen

On the small path leading from Chlingenstock to Fronalpstock

Hike von Weggis up to Rigi Kaltbad, 4h hike, 5h on tour, 1400 meter altitude

• take the car to the cable car station in Weggis on the north border of the lake Vierwaldstätter. Park there.
• start your hike right here all the way up to Rigi Kaltbad via the so called Felsentor trail
• terrific tour with fantastic views and very nice trails, some of them as single trails
• at Rigi Kaltbad there are many restaurants and shops for recreation
• take the cable car back down to your car

Eggberge hike, 4.5h hike, 5.5h on tour, 1200 meter altitude

• Take the car to Flüelen (at the south end of the lake Vierwaldtstätter), follow the road to Altdort ond go on direction Klausenpass.
• Passing Altdorf, 3km direction Klausenpass, already up the hill, a cable car station with a small parking area is on the left side called Brügg / Bürgelen.
• Park your car there.
• start your long hike up the hill direction Schwand / Eggberge
• When you reach the plateau there are many small inns and taverns, original Swiss with original Swiss charming service
• As well terrific views in an outstanding region
• There are two different cable car stations on the plateau. Doesn't matter which to take, both lead down to the car park where your car is

Alternative to Eggberge, 4h hike, 5h on tour, only a few meters up and down

• Park your car on the same location as above
• This time take one of the cable cars up the hill. Each cable car has a middle station where you have to change to go up to hill. Go up to the hill to the plateau.
• Start your hike there direction Klausenpass (east). This hike is just fun, all the way a bit up and down, never that hard, but about 4 hours to go.
• The hike ends where the hiking path hits the road coming from Altdorf to Klausenpass 2km before you reach the top of the pass.
• There is a bus station. Take the bus down to Altdorf. It goes about once an hour until about 6pm.
• Next alternative: go by bike. The cable car will transport your MTB up the hill. Instead of hiking go for biking. The trail is easy, so the normal average bike will manage it.
• With a bike you can of course go the last 2km to Klausenpass and of course cruise down the road to your car.

View from Schwand direction Klausenpass, only 3.5h left to hike

Rickenbach to Klewenalp hike, 3.5h - 5h hike, 4.5h - 6h on tour, 1000 meter altitude

• Take the car to Beckenried on the south border of the Vierwaldstätter See, park at the cable car station
• your hike starts here going up the hill either to Klewenalp or direction Stockhütte
• Down from Klewenalp the cable car directly goes to your car park
• From Stockhütte a different cable car goes down to Emmetten. There you have to change to the bus to go down to the cable car station in Beckenried

Hike from Schwyz to Mostelegg, 4.5h hike, 5.5h to go, 1100 meter altitude

• Take the car and park in the center of the village Schwyz. Do not park at the railway station. The railway station is 2km down in the vally from Schwyz center
• Start your hike in Schwyz direction Hagenegg or Mostelegg. Search for the yellow hiking signs in Schwyz. Best position to start and find the signs is at the central bus station. All hiking paths are signed there.
• If you go for Hagenegg you end at a small mountain taverne with a nice terasse right under the massive of the so called "Kleiner Mythen" a very impressing peak there.
• At this taverne you enjoy a teriffic view over lake Vierwaldtstätter
• Starting at Hagenegg go direction Mostelegg
• If you go for Mostelegg from Schwyz you are already there :)) (Mostelegg is in between Hagenegg and the target of the hike)
• Go direction Mostelberg via Herrenboden
• At Mostelberg there is a station with a few tavernes, child animation, a large slide.
• Take the cable car down the hill to Sattel
• In Sattel at the cable car station is a bus station going back to Schwyz (14 Minutes).



Between Mostelegg and Mostelberg, View down to Lake Lauerzer, Schwyz (we hiked by bike)

Take your time. Come to Switzerland and enjoy terrific hikes and trails. Conserve your knees and meniscus. You will love that - in the last century - the English railway constructors and rich Lords tried to construct a cable car or train on nearly each peak, hill and mountain.

You will love Switzerland. You will find a sometimes interesting and different view on hospitality in the taverns and small restaurants far away from the shopping centers. You will learn to love that as well... I love it.