Homepage Ralf Bürger > Blog by
 
 

"Life is what happens to you while you're busy making other plans."
(John Lennon)

 
 

 
 

Apr/19/2013 - Process Tailoring Top-Down or Bottom-Up?

 
 

Big companies and worldwide corporations, who develop a lot of software or complex systems usually try to get a grip on their projects by unified development processes. To "get a grip" usually means "make them comparable" and thereby "measurable". The responsible managers want to realize as early as possible when projects are "leaving the track", i.e. not working compliant.

Then the processes become as complex as the projects and respect everything, what the projects should respect in an ideal situation. By this the processes cause efforts that the projects wouldn't have without these processes. And the projects don't get better by this, their teams only complain even more, because now they have "with the processes" more effort than "without the processes". But it is impossible to work without processes, one is usually just not aware of the used processes.

Usually these companies react to the complaining teams by tailoring the processes to make them fit to the different types of development projects. So a small technical project maybe can leave out the "Functional Safety" (ISO 26262) aspects of the processes, because the system under design is not safety relevant. A small software development project maybe is doing everything on its own, without sub-supplier, and may then leave out the sub-supplier management process (ACQ.4 in SPICE).

 
 
 

So then their is a maximum process with options to cut; this process maybe can respect the situations mentioned above, but finally the software development team can not choose an iterative incremental approach to deal with the complex project requirements, and an embedded system development team can not respect, that the hardware must be ready pretty early to achieve market certifications, but the software will be modified "up to the very end". In that case at the process gates the different views of Builds, Releases and Samples don't fit together. So on the one hand the process is far too complex, because it respects every ideal situation, but on the other hand it is still not complex enough, because it would need much more for an instanciation in the projects. At this point often it all breaks apart!

Tailoring top down

 
 
 

Yes, project teams do have to cover this complexity! But is it a good idea to cover the complexity of the real world with a formal process? Will this help to reach the goals? Will this make it easier for the projects, and will it really be easier to compare and measure the projects? Or are the companies only dreaming and believe that the complexity of the projects can be managed this way? Why are the processes not created in a way that supports the work in the projects, instead of trying to support the controllers and managers? Development processes should support the developers and should not setup a fake management situation that looks like it could manage the complexity.

 
 
 

In an earlier Blog I have stated, that development processes - opposed to production processes - should be a reuse of "base practices", that thereby become "best practices" for the certain project. Following this approach various valid combinations of base practices do exist, that in summary show different processes, but the processes of the projects thereby are assembled "bottom up" by combining the selected base practices, and not by "cutting down" a maximum giant process world. This approach also simplifies the instanciation within the projects, because for several similar work packages or for several iterations a base practice is simply integrated several times into the project process. Then the complexity of the processes mirror the complexity of the need of the projects.

Tailoring bottom up

 
 
 

The progress of the projects of a program or portfolio can only be measured by comparable milestones, that do exist with this approach the same as with the traditional cutting-down-approach. So nothing must be changed in the mindset of the controlling or management. But the process design requires much more experience with flexibility: the process designers should rather be experienced with software development than with traditional industries!

Big problems derive from the tools, because the tool aided process design is not yet adapted to iterative incremental agile approaches. If you think the changing of the mindset described above up to the end, than the tailoring happens where it belongs to: in the responsibility of the project manager. And the project managers plan their projects with a planning tool, it might be Microsoft Project, SAP PPM or what ever. When at the end of a project during a Lessons Learned session the best experience will be extracted as schedule template fragments, it can be reused in the next project. In addition these fragments should be described in the context of the development processes, because these schedule template fragments can not be self-explainable.

For such a switch of the view not only the mindset of the process designers and the functionality of the tools must be changed, but of course also the mindset of the managers and of all users of the process model and the tools. The competence of the project manager must be enhanced together with the responsibility.

 
 

 
 

Mar/18/2013 - From Project to Project

Development processes of projects (e.g. for software, hardware, mechanical design) should be a reuse of base practices of former own or foreign projects. Today typically no project has to start from scratch regarding the used methodology, because not everything is done in a totally different way than ever before. In reality in all relevant projects you will find team members who do some tasks in the same way as they have succeeded before.

Therefore base practices should always be detected in projects and should be collected from them. Based on these practices process variants can be tailored. New projects can choose from the base practices those ones that are most suitable to their needs. By this not only single team members are learning from project to project, but also the whole organization. And thereby the projects can learn from each other.

Ralf Bürger - Processes, Projects, Reuse, Best Practices - Mar.2013

 
 
 

While a product engineering process - in the common sense of technical engineering - can often exactly tell which steps have to happen in which way, a project always is somehow unique - somehow! During a project for sure something unexpected will happen, that requires a best possible reaction. Therefore during a project the chosen process and the selected methods might change: whole process steps maybe need to be changed or single methods maybe need to be exchanged.

Then the processes that are used in the projects can be measured against the tailored variants of the standard processes of the company (e.g. by CMMI or SPICE), because both of them are based on the same method sets. By this the standard processes become reference processes, that wrap the different possible methods. Then one should detect and collect the new evolving base practices of the projects to enhance the reference processes. These captured base practices can be supplied to the next projects, and this results in a continuous improvement process. Thereby the maturity level of the corporate collaboration can raise over time.

 
 

 
 

Mar/08/2013 - My reference customer AOS

The work on the software for my reference customer >AOS< is good on the way. The department of the company is working on ISO 9000 certifications for the members of a society. These member companies are producing and selling eyeglasses. The job of the software is to manage the audits, certifications, trainings, questionnaires, etc. The data model and the query model of the database were growing rapidly over time. But also the import of the information from the PDF files of the questionnaires and the automatic interpretation of those data were more effort than expected (by the customer). At least for a piece of software that I am developing all alone beside my main consulting business.

AOS - PDF questionnaires

 
 
 

As usual it was very important to get the new software into the business quickly to find the real requirements. Thereby the software can be improved in a way as it is really needed. The agile methods have been successful in this small project also. And as usual the most and biggest problems are not in the software itself, but rather in the collaboration of the involved business units, in the interfaces of the technical systems and in the understanding of the real business. By using a strictly iterative incremental approach we were able to gain additional business value with every software release. We could even improve the questionnaire with its statistical interpretation. We organize this small project with the few members with a central LOP (List of Open Points) only. In this LOP we keep the requirements for the next releases as well as the bugs, the change requests, the priorities and the small open points that we find while we are working hands on. We even don't classify these items - it's simply all work to be estimated, planned on releases (iterations) and finally even to be done and delivered ;-)

AOS - statistical interpretation of the questionnaires

 
 
 

Because it is a VBA development in Microsoft Access, it was once again useful to distinguish the data file from the program file. Thereby the program can be developed and enhanced independently from the maintenance of the data. In the data file we maintain a really good data model and that helps as much as maintaining a really good hierarchical query model in the program file. Thereby the typical chaos of the queries can be hold under control. And thereby the development of the forms and reports gets a solid base. At least I really try to do the right things right - isn't that real process tailoring?

 
 
 

AOS - data model  AOS - query model

 
 

 
 

Jan/13/2013 - Software, Made in India

I know that programmers in India only cost 21,-EUR per hour,
I know that the education in India is exceptional,
I know that the software companies in India are certified on SPICE level 5,
but I also know that this software paradise quite often does not deliver the software that was expected!

It would be much easier if the mentality and culture would be the same! "Yes" quite often has a different meaning, to continue working does not always mean that a solution has been found, and it is anyway only done what the boss says! All this is not really new, but also all this didn't change over the years. So many things would be easier, if the international globalized companies would develop culturally adaptable organizational frameworks for their process landscapes. Then it maybe would not be necessary to coach a strict result driven development process in India that requires the collaboration of 19 roles within a team.

We will not quickly change the culture of a foreign country - and luckily we don't want to try that any more in our days. So if we want to work with them, we have to adapt to them and must want to understand their mentality! I have traveled enough to know that the organization of a project can not work in the same way in every country!

But how can we define a culturally adaptable organizational framework for development processes? I think first it would be easier if the process landscapes would be assembled dynamically bottom up from single elements, like base practices. More about that later on.

 
 

 
 

Oct/08/2012 - Architecture Open Space

In November we will present our fourth Architecture Open Space. >Open Space< is a very agile type of event, where the attendees can modify the agenda on the fly all the time. We will have several threads in parallel, and you may switch to another thread immediately if you don't like the current one. And if you don't like any of the running threads you simply go to the coffee area, where you will find an interesting discussion for sure. But if not, you simply throw a new topic into the agenda that you would find interesting. And if you don't find anything interesting at all on this event, you simply leave, because it might be the wrong event for you at all. You can find more information regarding this type of event by clicking the link above.

 
 

For the first time now I'm one of the sponsors of this event. I know the other hosts since a couple of years now, and even some very interesting attendees join in for the fourth time. So if you are interested in software architectures and can throw in good discussion topics, then you should attend. At least you should be able to understand German - it's no problem to talk English on the other hand. Of course you get decent meals and lots of coffee during the event.

Architecture Open Space

 
 

On our corresponding >website< you find all important information you need regarding this event, so save the date, the location and the very small price. You may also suggest some topics for the agenda in advance. And of course you can register yourself quickly and easily on this website.

 
 

 
 

Jul/12/2012 - "The Brain"

 
 

For years now I use tools for creating and managing Mindmaps. The creation often is quite easy: One got a topic, places this in the middle, then collects some groups around it, gets into the details, then mixes it up, modifies and adds branches - and then the meeting is over and it's time for working it up.

The problem is that if the maps shall last for a long time and during this time one detects ideas to be added or modified or to be linked with other issues, so when it gets to be a really serious application of appropriate complexity, then it quickly becomes stiff and difficult - the mind map can't really follow the "changing mindsets". And exactly when a high degree of innovation is associated with a certain creative phase, it is most important to have a flexible tool. I'm really a friend of a binding requirements engineering, but I also learned when it helps and when it hurts. I always call this a conscious approach to ones own situation.

It always gets extreme when I try to manage my own confused thoughts for a long time in one tool: My ideas about certain issues, new book content, feedback from my seminars, impulses from conversations, random hits on the Web, my action lists from my client projects, thoughts on the next vacation, etc. I want to pack everything into a single tool in a single area and then the tool should be able to follow my particular focus: When I can take the time to continue working on my book (or this website), then I will just focus on this issue and I want to have all my thoughts at hand again, which I have gathered in this context over the time - and only those! But afterwards I will focus on something else and I want to know everything that I had gathered in that other context before. And when I get a call from a customer, I immediately want to have everything on the screen that belongs to the related customer project. I also want to write down the new input then - even totally different aspects that I realize (maybe it's a spontaneous idea for a book chapter).

Do you know movies like >Minority Report<? Those movies often show a >user interface< that picks up the ideas of former visions and researches. And they inspire thousands of developers and researchers afterwards. In my opinion lots of things that are realized today relate to those movies, and I often have to remember them when I get angry about the bad usage of software tools, whose developers were asleep for the last 20 years. The James Bond movie >Quantum Of Solace< shows a great user interface alternative, that is a little bit more realistic and more systematic, even 6 years after the Minority Report (2002) - and the Bond movie already is 4 years in the past now. The user interface of The Brain works different than others and often different than expected, similar to Prezi (see one of my older blogs); but the designers and developers have found a refreshing new approach (or have watched movies), and when you try it out for a while it's really a great experience!

Check the video on the >homepage< of "The Brain" and my adjacent screenshots. You can download a trial edition of the tool also. I'm excited even though I have not discovered everything yet. At least the last few weeks were much more exciting for me because of this tool. I haven't used all the other tools for managing mind maps, notes, actions, open points, etc. for several weeks now! I really love it that the tool is not "deleting entries" but "forgetting thoughts". By the way: I have taken the adjacent screenshots all from the same Mindmap - just from different "angles" with different focuses!

The Brain
>magnify<

The Brain
>magnify<

The Brain
>magnify<

The Brain
>magnify<

The Brain
>magnify<

 
 

 
 

Jul/06/2012 - Leipzig

 
 

Leipzig is beautiful! Maybe today even more than ever! Follow Goethe and others, and discover the beautiful city. It is also really noticeable how many tourists can be seen on the roads. So whenever you come to Germany: don't forget to visit Leipzig! Unfortunately I didn't have much time myself, because I have only been in Leipzig to visit Rüdiger Strohmeyer, owner of >PiA-Consulting<. We have done some projects together over the last years, and we are coaching totally different content with different approaches. So we have to talk now and then about our ideas and views. Actually I have just been for lunch in Leipzig and spent the 10 hours on the train working hard on my current projects. Next time I will stay a few hours more to see some interesting places in and around Leipzig - for sure!

Leipzig
>magnify<

 
 

 
 

May/25/2012 - iterative what?

For more than a dozen years now I have been preaching that software should be developed iteratively, that means in loops with the same process idea, but each with new content. So these are not real repetitions - I consciously say "process idea", because this could be waterfalls or V's or whatever; and that may vary from iteration to iteration. At least it shouldn't be freestyle, what often happens with Scrum, because the team decides by themselves with which methods the requirements of the product backlog will be implemented, without anyone verifying whether they really are able to do that by themselves. Rather an action model should be used that has been tailored consciously by experienced people - ideally it's tailored for each and every iteration! (For the young Scrum enthusiasts: an "iteration" is what you call a "sprint").

However during the first years I've always said iterative incremental, but I've become more cautious over the years. Meanwhile I see the alternative: the iterative evolutionary approach. The three words "iterative", "incremental" and "evolutionary" haunt around in the literature and on the web for quite a while, but up to now I never found a clear classification; these words are used in any combination or are considered synonymous. Usually "iterative incremental" is equated with "evolutionary".

There are projects where the "challenge" can completely be overlooked in advance; it can be fully analyzed and defined. And it will be implemented step by step (iteration by iteration) - and perhaps it will be released in the same way. In this case you can plan completely how the new product version will grow up, until it gets the completeness and maturity that has been expected. In the end it may even be tested against the original requirements and may be approved. Nowadays I like to name this approach iterative incremental.

At research projects or extremely innovative products often there is an idea, what it will look like in the end, but whether this really works, which steps will be required, how the product in the end really will look like, and when which interim versions will be released, is absolutely uncertain at the start of the project. The product will grow up here in loops too, and they each might have a similar process approach, but in its entirety these iterations are not predictable and projectable. Nowadays I name this variant iterative evolutionary, because an evolution is a kind of development where the next options can be seen only when the previous ones have been implemented. For alternatives an evolution always will continue based on the best results - and that is not projectable right from the beginning.

I strongly believe that this conscious distinction is extremely important at the beginning of a project. In both cases the project starts with the requirements analyses, and the implementation begins as soon as the first workpackage is analyzed. In the incremental approach the analysis can be continued in parallel to the first implementation. In the evolutionary approach you have to wait for the results of the first implementation before the next analysis may start. In the projects this can make up a huge difference; everybody should be aware of this difference! Anyway it really helps me, and it also helped those whom I explained it while they were setting up their projects. At least it helped more than most of the definitions and wordings that can be found in the literature and on other websites.

Of course - as usual - there is not just black or white: quite often you have to look for the compromise. Some planned projects will get a surprise, and some innovative approaches will turn into a predictable project after the prototype phase. In your project you always should have these different iterative approaches in mind, and you should steer your project consciously.

 
 

 
 

May/21/2012 - Attending important meetings; or boring ones; or maybe important? ;-)

I received this e-mail thread today and I only replaced the names - I didn't change anything else; really! And this is the original version because English is the defined language in that project. Read this e-mail thread from bottom to top - it's chronological.

-----
To Ralf (in the role of the project management coach)
fyi :-)
Rainer
-----
To Peter, (CC Rainer)
Please see Rainer's question below. I do not have any experience with [xxx] Supplier Conferences. What are the expectations?
Thanks,
Paul
-----
To Paul
I just found out, that I am also invited. Would you recommend, that I attend as well via phone ? - would it be unpolite to leave after 30-60 min ?
please advise.
br, Rainer
-----
To Rainer
This is a standard OEM project supplier kickoff conference. You have to sit for hours and listen to each of the key launch managers give a talk on the importance of "this project" and how important it is to succeed.
Unfortunately it is mandatory attendance.
Paul
-----
To Paul,
do you know what this is about ?
br, Rainer
-----
To Peter, (CC Rainer)
Please add Rainer to the Invite list on your meeting notice. He may want to call in and listen.
Thanks for sending this information.
Paul
-----
To Paul
Here is a meeting notice I received, disburse as deemed necessary.
Peter
-----

 
 

 
 

May/18/2012 - Prezi instead of PowerPoint?

 
 

When complex issues shall be discussed where you repeatedly branch into certain details, but on the other hand the big picture must stay in the scope, then Microsoft PowerPoint quickly gets to its limits. You can then use a mind map, but for presentation purposes it is often bulky and unattractive. You might use Prezi instead, that you might use online or -for bigger tasks- offline. Within a large scale image you can place lots of details and you can zoom in and out. The spots, frames and paths for this zooming are predetermined by you. Of course, texts and images or videos may be added, and the individual elements can also be rotated. This is great, for example, when a whole development process has to be explained, where you want to zoom into sub-processes or even single steps, but then again you want to zoom back to the whole sub-process or even the entire process.

Prezi Logo

 
 

I'm currently creating a Prezi as a presentation of my profile. Of course PowerPoint would do this job too (and it did in the past), but it's more dramatic and interactive with Prezi, because I must not follow the path but can zoom in individually just by a click of the mouse.

Simply click to >this< link and when you get to my Prezi select at the bottom right "More" and "Fullscreen" and afterwards "More" and "Autoplay" to see what happens! By pressing the key "Esc" you can quit the show anytime. It's still in German but to get the idea of Prezi it doesn't matter.

 
   

Update May/19/2012: I just have added the Prezi overview officially to my website: I have created a new >page<, that can be accessed directly from the menue also, via "Professional" and "Overview".

Update May/20/2012: And now the new page and the Prezi are available in English also (as far as possible).

 
 

 
 

May/17/2012 - Exciting Conference

 
 

The small specialized conferences still are the best. In this case again it was a great deal for me: some really good new contacts, exciting special speeches from Audi, BMW and Daimler as well as from special software companies; I also gained some good hints related to tools and the iPad. It was interesting how many attendees used the iPad and how proper it suits as a conference tool: it's easy to hold it in your hands, you can take fotos (e.g. the one you see here of the specially prepared SLS), you can take notes quickly and easily, look up the Web (of course we had WLAN access), check and answer e-mails, lookup the conference program, etc. For me, conferences have become the new main argument for the iPad.

Mercedes SLS

 
 

I am particularly pleased about the good contact that I could get to the organizers of the conference - thanks to Juergen. At the next event of Kugler Maag Cie in January 2013 I will attend as a speaker with my special presentation about my agile approach to creating project specific action models. We will meet soon to discuss details. Then I will present my book with my deck of cards.

Kugler Maag Cie

 
 

 
 

May/16/2012 - Roundabout vs. Intersection

 
 

Today I met someone who is involved in change management of large scale organizations, mainly by changing of mindsets - if you need that, simply contact me. During a discussion he mentioned something like "... just like roundabouts and intersections." From that point I didn't follow the discussion any more, but only stayed with this picture.

Looking at an intersection the participants will either be actively directly controlled by a set of traffic lights or they have to deal with several directions simultaneously. At an intersection with traffic lights there will be no discussion because the traffic lights must be respected. At intersections without traffic lights anything goes wrong anytime.

Intersection without traffic lights

 
 

Looking at a roundabout only the basic rules are given: every participant has to drive in the same direction, leaving the roundabout must be signaled and you may enter the roundabout only at a gap. This last point is decided by every single driver, but usually it works out really fine, because it's a simple decision.

Opposed to other countries Germany took really long until the roundabouts got established and critical intersections got converted into roundabouts. Other countries have been ahead for decades. In Germany the people like traffic lights, because they bring the maximum safety, but they are really expensive and less efficient at the same time.

Kreisverkehr

 
 

In quite some development projects it's absolutely not wrong to replace the heavyweight and complex processes by efficient methods and individual responsibility. Quite some situations should be re-evaluated and I'm sure that I will use the picture above quite often in the future - thanks Michael!

 
 

 
 

May/15/2012 - "Hauptsache don't get Pleite!"

At the conference today we had a lot of discussions about the different forms of Open Source, even the company internal open source projects. Exciting! I've never understood, how the architecture can be adjusted in the large and longterm scaled open source projects. Today I learned that some groups meet for refactorings in "hackathons" (hacker marathons), and sometimes they do a common refactoring with a number of people for even 20 hrs a piece. That is supposed to be as efficient as a regular work of three months in some other projects. The mutual respect and help is supposed to be impressive!

New for me was the approach of open source in hardware, where online the layouts, the housings and the firmware are created commonly. The Eagle layouts can be uploaded to the Internet to manufacture the boards - only the quantity has to be added for the production. And for the housings some companies exist that create them directly from the designs on 3D plastic printers. For a few samples or small quantities this is good enough anyway. And some large producers (at least in China) produce them in large quantities and make their profit (at least they don't have any development costs). Anyway the newest version with the current updates and bugfixes and specialties always is in the open source community.

Of course I asked the typical question: "Well, how do they make their money?" and the answer was a typical one for the communities: "Hauptsache don't get Pleite!" (a German/English mix like "The main thing is not going bankrupt!"). So they live on small lots, individual adjustments, orders due to their gained expertise and finally from sponsorship as with open source software: Companies pay them to develop new things highly efficient in the teams of the open source community and after the project they will repeat it professionally within the company based on the experience. This way is much cheaper for the companies than starting pre series projects or prototyping projects within the company.

However, the communities in fact usually have some organizational problems when they get too big and don't have a central sponsor. In this case we talked about a community of 1200 people, where currently quite something gets confused, because the central respected gurus don't have a complete overview and they also don't have any interests in getting controlled. I really find it very interesting and would like to dive a little bit deeper to see how that works. Finally I got invited and I'm really looking forward to it.

 
   

I just had some e-mails with Amin Zayani and he sent over some really exciting web links. These show some open source hardware projects that started two years and one year ago and unleashed a wave of this type of projects and DIY (Do-It-Yourself) projects.

The first link shows 6 pages and a video, that gives an insight to the third link also.

   http://www.wired.com/magazine/2010/01/ff_newrevolution
   http://www.wired.com/magazine/2011/03/ff_adafruit/all/1
   http://DIYdrones.com/

I really liked these phrases:

   - The community must be well managed, well led, and well equipped with tools.

   - Here's the history of two decades in one sentence:
     If the past 10 years have been about discovering post-institutional social models on the Web,
     than the next 10 years will be about applying them to the real world.

   - The Web was just the proof of concept. Now the revolution hits the real world.

And finally the URLs of the blog and the site of Amin Zayani - a huge source on this topic:

   http://www.blogbouha.com/
   http://optimalabs.de/

By the way: the conference where we met was not one of the two events mentioned in his blog ("Conference Vs Barcamp"), but it also was a classical conference by its organization that goes directly between those two. Of course Open Spaces and other dynamic events are more effective and more open and faster, but they are still hard to find on those topics. I'm looking forward to his post on this conference ;-)

 
 

 
 

May/03/2012 - Paperless Office?

 
 

Sometimes my memories shoot me even 10 years further back in the past, when I developed an operating system in assembly language for a memory typewriter and at the same time all the world talked about the paperless office. And what do we have today, 27 years later? We're searching for our memory sticks among the piles of paper on our desk! Anyone who knows me, knows that this did not happen to me today, because I work as paperless as possible and I'm a real fan of the clean-desk principle, where the desk is always sparkling clean - also see >this< blog entry ;-)

Memory Stick

 
 

 
 

Apr./29/2012 - At least we have 2012!

 
 

Sometimes however it feels like 1995, at least on the notebook of my wife - that is an Asus (still no half year old) with Windows 7 64bit and an HP WLAN printer. The thing worked fine for a long time, but (without modifications) it suddenly prints only, if it wants. The download of a newer version of the driver, the uninstall/install and the configuration suddenly turns into a fiasco, because the setup wizard stops right in the middle. I have no idea what kind of mistake that was, the detailed explanations really reminded me of 1995, the problem-solving crashed and the uninstall by the Control Panel did not work anymore! Only the driver repair by using the original CD helped, and then suddenly it enabled the installation of a newer driver version. Now this thing is printing again - let's see how long! It's still a mystery to me why a driver with this content must have 57 MB unpacked - while my very first harddrive had 10 MB at all! If in 1995 - when Windows 95 with Plug'n'Play was released - I would have claimed that in 2012 we still would have problems with printer drivers, I would have been laughed at!

(The screenshot says "error during installation" and the details window shows "installation error".)

HP error message
>magnify<

 
 

 
 

Apr./24/2012 - I love triangles!

Fakes are copies that are sold as genuine!
People become actors when they play a role!
Teachers become trainers, when a coach helps them!
Quality can be reached only, when time and budget is invested!
Software works best, when you place it together with hardware into housings!

 
 

 
 

Apr./18/2012 - Doesn't "working agile" in fact mean "working structured"?

Lots of people rush into this new agility to get more efficient - or is it at least in fact to escape from the processes and paper work? I experience more and more that people in chaotic projects claim to be agile. In this case I always reply that agility means to be self-organized at the edge of chaos, but that this project already is far beyond ;-)

Is it possible to modify the software architecture after six years, after we have received so many change requests that all have been "stuffed" into it, so that now it's time to clean up the whole mess? Is this then the dreaded expensive software refactoring? Isn't it at least even more than the original definition of software refactoring? Isn't it possible to avoid this by front-loading? Do we need a rethinking just as from the waterfall model to the V-model years ago? Isn't it possible to distribute the refactoring over time, so that it is done always immediately after the change? Will many small refactorings finally not be cheaper than one big refactoring at the end? At least this was exactly the original idea behind software refactoring.

I claim if it's possible to make a huge refactoring of the architecture after a couple of years, than it's possible to do a small refactoring every couple of weeks after small changes. We do exactly the same with data models since ages: I always can "patch" something and after a while I do a refactoring with huge effort, I have to repeat the normalization process, have to adjust the data, etc.; on the other hand I can integrate each change in a way that everybody will think that it always has been exactly like it looks now. I have done this in a huge project for almost 10 years in steps of two months! I'm currently doing that again in a small Microsoft Access project: every few weeks I'm changing the data model a bit and it always is in mint condition!

 
 

AOS data model    AOS query model
High resolution - simply open separately in a new window.

 
 

The bigger problem with Microsoft Access are at least the queries, that always get more and more chaotic, that call each other, and the modifications are not really traceable. Since 15 years now I always split the Access databases into the program and the data: the data-.mdb (.accdb) holds the data tables only, the program-.mdb (.accdb) holds the queries, forms, reports and modules. Then I connect the program file with the data file. So I can maintain the data model in the data file - this file is "owned" by the customer. On the other hand I can maintain the query model in the program file - this file is "owned" by me! After the transition of the software usually the data model will not see that much modifications while the program changes all the time. Based on the separation I easily can maintain and test the software and plan the releases. I'm always changing the whole structure very carefully and adapt all models and modules very accurate so that it always looks like it has never been changed at all. This needs quite some effort, but it enables continuous maintenance and it protects from the big bang that requests a single huge refactoring.

Of course a huge modification of the business modell - and thereby the needs - requires a change of the software architecture, the data model and all other models and the software design including all the program code. But how often do I see increasing error frequency and weight because the software system simply is "aging" with all the changes done over time? "To be agile" means "to be ageless"! To keep a software system young in my opinion works only with more structure instead of less! As in our everyday business agility requires disciplin, consequence and continuous moving! How long can I keep everything tidy without the need for a big cleanup?

And please don't lough about Microsoft Access now! I'm related to server systems with Java, webservices and data warehouses as well as embedded systems projects with international distributed teams. All this works in the big scope as well as in the small scope, as long as the teams really want it. Of course the teams must have developed the corresponding mentality and profession and the corporate management has to provide the required frame. I currently undergo large and small projects at the same time but by nature I'm usually not allowed to write about the big ones :-(

So I claim that agile software development does not work in so many projects because the people slack off instead of working harder and sustainable. With experienced teams and team members the agile software development methods work really fine, but they do this already much longer than the method is named by this. All other people shouldn't learn the agile methods but should learn working more structured and more disciplined! I want to point out that this is not a short-term learning like collecting know-how or methods, but it rather means to be a long-term increasing of the people's competence and it requires continuous change in the people's attitude!

 
   

Note: I referenced this blog entry as a comment to this Forbes article of Steve Denning also:
The Best-Kept Management Secret On The Planet: Agile

 
   

Note via e-mail:

Hi Ralf,
I have just read your blog. I accidentally found your page while searching vor action models! I'm involved in a project right now, where the supplier adores the agile action models ... that project is crashing completely and it is exactly as you have described it! I really had to grin! Thanks for that great blog entry!
br from ...

 
   

Note from Steve Denning:

I agree that if people rush into Agile merely in order to escape discipline and process and paperwork, then chaos is likely to ensue. My take is that Scrum requires more discipline both from managers and from software engineers. It's not "the discipline of telling people what to do", but rather "the discipline of making timely good decisions based on shared understanding of problems."

The main advantage of Agile is not so much about becoming more efficient, though good implementations also achieve that, but about becoming more effective and responsive to customers, on whom the future of the enterprise more and more depends.

I'm not a software engineer, but my understanding of Agile and Scrum was that continuous refactoring is strongly encouraged. Allowing technical problems to build up over time is certainly inconsistent with the spirit of Agile.

The main thing is that Agile isn't a panacea. Badly implemented, it will have bad results. But what it does do is solve some problems that have troubled general management for many decades. It's important that we all learn from that.

 
 

 
 

Apr./17/2012 - Apple, make it bigger please ;-)

 
 

It's really great that the electronic devices get smaller while on the other hand more powerful - but the Apple Time Capsule is too small! No, I don't mean the memory capacity, I really mean the footprint. Our cat Amy really is a tiny cat, but the Time Capsule is even more tiny - too tiny! So Apple: please make it a little bit larger with the next release and add one more drive so that it heats up a little bit more; and a more cuddly cover would be nice too ;-)

By the way: I took this foto with the new iPad, that has a slightly larger footprint than the Time Capsule but it's still inappropriate for Amy, because it simply doesn't heat up enough! Apple makes a really bad job for some of us ;-)

Amy on the Apple Time Capsule

 
 

 
 

Mar./30/2012 - SAP PPM / IBM Rational DOORS - Requirements Engineering

Since two week I'm in a new project for the customization and integration of >SAP PPM< in a large company. It's the new version of PPM and it's the first time that it is implemented together with the new Version of PLM - at least in Germany. Before the decision has been made for SAP PPM about 600 requirements have been gathered from all departments. Now it is up to me in the role of a requirements engineer to manage and analyze those requirements with >IBM Rational DOORS<.

Since I have support from a DOORS specialist from IBM Rational I customized DOORS to support my evaluation schema that I describe in my book also. So in DOORS I have columns now for the rating of the complexity, variability and priority of the requirements. In another column the risk is evaluated automatically from these attributes - with a little macro programming behind it. These requirements are the ones that we derive systematically from the business processes. We also have imported and reworked the 600 gathered requirements and I now can relate them to create a traceability and to check for completeness and consistency (as shown in the linked video above). So I quickly found the first inconsistencies that will be discussed and removed next week.

The introduction of SAP PPM itself is really interesting too because it has to replace Microsoft Project and the existing risk management tool and has to support list of open points, multi project management, project portfolio management and resource management too. I'm sure that this will cause modifications to the business processes and workflows too, at least for the change management and the management reporting. Of course the customization and introduction is done by SAP experts, and therefore an additional external project manager has been established. Looks like an exciting project for the next couple of months!

 
 

 
 

 _
( \
 ) )
( (  .-''''-.  A.-.A
 \ \/        \/ . . \
  \   \      =\  t  /=
   \   |''''.  ',..'
    / //    | ||
   /_,))    |_,))

This is the beginning of one of my nine lifes,
but I don't tell which one it is ;-)