Recently my latest Whitebook was published, called ‘Integratie maar dan lean‘. The article focusses on solid tips to move your integration practise to a more lean version.
It’s in Dutch. International readers can use Google Translate. An English translation can be provided on request. Please leave a comment with your email. Have your integration lean 
Just found out I forgot to publish the Mind Map I used while studying for my scrum master certification. The mind map is based on the scrum guide. Download the scrum guide mind map pdf.
The definition of done is used to have a shared understanding of “done”. You can find a good definition of done example on this blog.
Since this blog is also dedicated to sharing resources that are valueable to me I decided to share my reading list of 2011 with you.
A great best practices book on integration. The first part provides description of the business value of Lean. It introduces the core concepts. As a manager that doesn’t need all the details you could just read this part and you can get a good grasp of the ideas presented.
The second part translates the lean principles from the world of manufacturing to the world of systems integration. It has great case studies that shows the principles applied in a real world context.
Part three of the book provides a “how to” guide. This can be used as a reference and as such is a great desk-top reference manual. This book is great and a must read for all technology and business practitioners and innovators.
Great reference (not a book that I read front to back) on Web Service Design from Thomas Erl and his co-authors. This book focuses exclusively on the contract part of the service. Due to the depth it is a extensive resource to use besides others. The book is filled with extensive examples on how to meet the goals of SOA properly using contract design.
Via the site of the publisher and on iTunes are additional service design podcasts by the authors of the book. Could be a great resource to start with.
This is a great book on problem solving, extremely useful and in a sense thought provoking. It structures problem-solving into a six by five visual codex. This makes sense; you can literally see the evolution of the thought processes and the development of the insights take shape through the pages. Fun read as well.
Certificate Professional Scrum Master I
Besides the Scrum Guide and a training, you can find additional Scrum resources i like here. While studying I created a mind map using the scrum guide.
As you can see in the picture in this post I succeeded.
Congratulations on passing the PSM I assessment! You have demonstrated a fundamental knowledge of the Scrum process. This qualifies you for certification as a Professional Scrum Master I.
Still wanted to share some thought and ideas with you I took from the LAC 2011 – the largest symposium in The Netherlands on architecture in the digital world. The larger part of this post is taken from the key note on Speed and Innovation through Architecture by Jan Bosch. He states:
Speed trumps any other improvement R&D can provide to the company.
Speed and time to market deliver far more value than increasing the efficiency of a process. This especially holds for non-repetitive process like (software) product creation. To increase the speed and reduce time to market we should focus on the following aspects:
Small teams work on the people side because a team member can experience the fruits of his or her individual efforts while on the other hand they contain the rewarding social element of camaraderie. Both are necessary for people to see their work as fulfilling.
On the process side, small teams increase speed because of the lowered need for coordination within the team and the existence of complexity. A team larger than three is required because of the need to learn from each other, the ability to deliver significant work and enable preservation of knowledge from the feedback the team has encountered. To get speed in the team at a high level the team needs to be self directed and managed.
First and foremost make sure your architecture enables you to simplify things! Keep in mind that rules and constraints can create complexity. And that is something you wanted to avoid when you started with architecture in the first place.
Architecture provides simplicity, compositionality and is designed in parallel with software development
An example would be to limit the number of things a team has to worry about during development. This could be done by applying the 3 API rule and there are other ways as well. Allways ask the questions whether the architecture enables the development team to perform.
In order to get speed into your development process you need to know/measure what people do, not what they think. Factor out opinion and chose data. To get proper results here you need a short PDCA cycle. Check and measure to get results back into your development process. This requires that you release early and often. Which in turn demands automated deployment and test.
The basics of Scrum can be found in the Scrum Guide. Besides that there are loads of resources available on the subject. In this post I’ll share a few Scrum resources with you I recently discussed with my colleagues:
Besides these the online lean and Scrum resources library of one of my colleagues gives some other great hints. You might also like to read his selection of 10 from ‘Corps Business: The 30 Management Principles of the U.S. Marines’.
Working at a customer in recent months I was on the receiving end of a Scrum coaching project. Unfortunately this ended early. And I started thinking about what I could learn from my angle as a team member. I came up with the following cases and hope they can be helpful for you as well.
If you take the role of coach in a certain expertise field, stick to the that role. This will give you focus and a higher probability of success in the field in which you perform really well. In addition to that, this is the thing/trick you are hired for. It is great if you can deliver additional value, and get the team of organization you are coaching to a higher level, only after you are delivering what you should deliver.
For example you’re coaching in SCRUM, and there is loads of work to do to get the Product Backlog in good shape, getting the documentation up to par, and help the people with the SCRUM way of working; it might not be the time to debate all kind of possible coding issues, try to remove commit hooks from SVN (requiring an JIRA issue number) and other stuff like that.
Should you as a coach decide to be a part of the team, you also have to commit to results delivered by the team (that now includes you). After you check out the code it doesn’t shown you value individuals if the only thing you do is place remarks and object without not delivering anything yourself (let alone things perceived as value by the product owner).
Stick to your role.
Focus on your assignment and the results you have to deliver. In the case you are coaching a team in the world of SCRUM it is not necessary to start a debate on all design, technical, technology and frameworks choices that are made in the first week. When valuing individuals and interactions over processes and tools, also keep in mind that it is the team of those individuals that made a range of choices. Some of them could very well be the result of much (heated) debate.
Focus on your assignment and the results you have to deliver. Don’t (re)fight every battle.
Just uploaded the presentation I gave at the Seminar “Lean & Agile IT: beter resultaat, betrokkenheid en IT volwassenheid” (Dutch) on Lean Integration. Besides the aspect of getting a lean process to create integrations we also focused on how integration is lean in the sense that it can create value.
Martin van Borselaer asked me to present at a seminar he is organizing on Lean and Agile IT. I’ll be presenting on Lean Integration and will probably also offer a peek into the Integration Factory.
This seminar will take place on Thursday September the 15th at our Whitehorses head office in Nieuwegein, the Netherlands. It’s in Dutch and aimed at our customers or potential customers. More information on the seminar program.
We’re looking forward to share our ideas with you. Hope to see you there!