The Agile Practitioners group recently held a pecha-kucha event at Zuhlke Engineering. The talks were great! The content was intriguing and the Pecha Kucha format added an extra edge to the presentations.
We learned a few lessons that will help improve the next Agile20x20 event.
Here are the talks
Christian Heldstab does a great job of presenting Getting Things Done
Abid Quereshi exlapins the core values of Scrum
Railway buffer at the top of Pikes Peak, Colorado Springs CO
There is an informative slide deck on the FactoryPhysics website entitled A Fast Cycle Time Story. This slide deck was created by two Intel Products employees namely Tim Skowronski and Joan Tafoya.
The slides cover many aspects of lean manufacturing, one of the topics covered is The Buffering Law
Systems with variability must be buffered by some combination of:
- Inventory
- Capacity
- Time
Tafoya and Skowronski explain the implication of this law
If you cannot pay to reduce variability, you will pay in terms of high WIP, under-underutilized capacity, or reduced customer service i.e. lost sales, long lead times, and/or late deliveries.
The following variability buffering examples are provided:
The X Penny Game is a simulation game exploring the effects of WIP limits. It is a combination of Karen Greaves modified Scrum Penny game with Karl Scotland’s version of the Ball Flow Game.
This game is geared to show the importance of limiting the work in progress and to explore the following formula (implied by Little’s Law)
Flow Time = WIP/Throughput
The game is designed to work with 6 to 12 people – we had 8 players and 1 facilitator
The team divides into the following roles:
We had a total of 8 players (6 workers, 2 efficiency experts).
The team organises themselves around a table. The image below shows how our team arranged themselves. Each worker has an empty area on the table directly in from of them referred to as a workspace.
It is important to mingle with other members from our industry. This keeps us up to date and stops us getting too caught up in a closed off world. If you would like to have face to face discussions with other professionals you may wish to join us at one of the Agile Practitioners events. This London based group will be meeting at least once a month. We will be discussing a variety of topics. While we don’t plan to replace any of the existing Agile groups, we do intend to be intriguingly different.
Recently we started using avatars on our Kanban board. We are certainly not the first to do this, however I was surprised by how excited and rejuvenated the team became. If you have never tried this I recommend you suggest it to your team and see if they go for it.
Not only is it fun, but it is also practical. With one look at our board we can see exactly who is working on what and who they are working with. Each person has one avatar on the board, therefore they can only work on one task at a time. Occasionally someone will start work without updating the board, but this is very seldom.
We went for the classic South Park characters, each team member got to draw themselves, here is the result:
You may have noticed that my character (Daryn) is a bit stressed out. This is a reminder to myself, that as the ScrumMaster I should not get overly concerned about everything. I need to trust in the team and leave them alone to get the job done. I need to remember that a ScrumMaster is a facilitator and not a manager. For me, not acting like a manager is the most difficult part about being a ScrumMaster.
Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5
JSDoc is an open source tool used to add inline documentation to JavaScript source files. JSDoc is based on the javadoc tool. Many of the javadoc characteristics have been included in JSDoc. An example of using JSDoc can be found here.
DOM Inspector is included in the Mozilla Suite and Firefox browser. This tool provides a graphical user interface that enables a user to brows the document object model of any site. One can view, update and insert DOM attributes dynamically. In order to assist JavaScript developers, DOM Inspector can be switched to JavaScript Object mode. This shows all the properties and methods available to a JavaScript for a particular mode. DOM Inspector provides a JavaScript evaluation window that allows the user to execute JavaScript against selected nodes. There is the option to use CSS Style Rules and Computed Style information. This allows a user to examine the CSS attributes associated with different page elements.
Firefox JavaScript Console is a tool that logs JavaScript errors found on a page when the page is rendered. The Firefox JavaScript Console gives ‘compiler-type’ messages. It describes the error that occurred and the gives the line number.
Firebug integrates with Firefox and provides many development tools. Firebug has a version of a DOM inspector that enables a developer to find elements. CSS support allows settings to be altered and viewed. Firebug allows one to monitor the network activity in order to determine how long it takes for different sections of a page to download. A JavaScript Debugger allows one to debug and step through the JavaScript at runtime.
Index | Part 1 | Part 2 | Part 3 | Part 4 | Part 5
The XMLHttpRequest object is restricted to run within the browser’s security sandbox. Any resources requested by the XMLHttpRequest object must reside within the same domain from which the calling script originated. Therefore the XMLHttpRequest object is constrained to requesting resources that reside within the same domain from which the script was originally served. The W3C states, that in the future The XMLHttpRequest Object specification will define a way of doing cross-site requests.
There is an overabundance of online documentation stating that Ajax introduces multiple security threats. These threats include fake requests, denial of service, cross-site scripting (XSS), reliance on client-side security, and more. Jeremiah Grossman’s article, Myth-Busting AJAX (In)security, maintains that these security issues existed before Ajax and the recommended security best practices remain unchanged. Part of internet security basics is to distrust the client. Ajax is a client side technology and requests need to be treaded with the same caution as all other calls.
Web users have become familiar with using classic web pages. Users have become accustomed to using browser features such as the back and next buttons. Ajax calls are not loaded onto the browsers navigation stack. Therefore the back button will not undo the last ‘Ajax operation’. Developers need to explicitly cater for undo operations.
Ajax enabled pages have a notion of state; this state is altered as the user navigates through the site. The browser is unaware of this state, and it is not reflected in the address bar. Therefore users are not always able to book mark a certain page state. Developers need to consider this when deciding on when to use Ajax.
The asynchronous nature may make page updates difficult for the user to notice. The developer needs a way of drawing the user’s attention to the modified section of the page. The ‘yellow-fade technique’ has become common practice. In this technique the changes are highlighted with a yellow background, and the yellow fades gradually. These and other techniques are becoming familiar to web users.
About a week ago I noticed some incoming links from Computer Weekly.com. I assumed that someone had commented on one of my posts, so I browsed there wondering if it was a positive or negative comment. Once the page loaded, I was completely surprised. It turns out that this blog has been short-listed for the Computer Weekly.com IT Blog Awards! This came as a complete surprise to me.
This blog had really humble beginnings. In fact it was not even my idea to start a blog, it was my work that encouraged me to start one. Initially I felt that I did not have that much to contribute to the world at large. In fact I still don’t feel that my blog is as innovative as some others, although judging by the response to my ‘Routing In Rails Tutorial‘ it appears as if I do have a nice way of explaining things. I guess this is one of the main reasons I have been voted onto the shortlist.
The competition ends on the 31st of July 2008. If you would like to vote please go to this on-line voting page. This blog can be found under the ‘Programming and technical blogs’ drop-down list. It is a surprisingly painless exercise, it takes less then a minute and no registration is required.
Thank you to all of you who have voted for this blog.
Daryn
In part 5 we looked at RESTful routing. In this part we continue to explore RESTful routing, by examining nested resources.
I originally planned to cover nested routes and to cover two questions posted to me in previous comments and emails. One question was with regards to ‘one to many relationships’ e.g. an album has many songs. The second question was from Tom in part 3; this was about adding save as functionality.
In trying to answer these questions I created a new application – a text editor with a version history. This has turned out to be a fairly interesting piece of work. I then changed my mind and decided to include it in a follow up post. I am hoping to have that out later this week (before Friday the 11th of July). As the ‘follow up’ post will have a practical example of nested resources, this post will not have the usual practical section with the experiments.
Returning to the familiar Music Store application, imagine we added songs to the application. Like Albums, Songs are resources and we could expect to access a song with this URI:
/songs/124
We could then perform the required CRUD operations on that URI based on the REST API as discussed in part 5.
An album has many songs. We can express this within the URI e.g.
/albums/10/songs/124
Once again we could make use of the HTTP verbs to perform CRUD in a RESTful way.
In this particular implementation, this URI does not mean that this is the 124th song of album 10 - it is possible for it to be the fist song of album 10. The URI is pointing to the 124th song in the system.
If we wanted the URI to state the song\track number of the specified album then we could alter the above implementation. Then we could expect to see URIs of:
/albums/10/songs/5
and
/albums/11/songs/5
This would not result in a URI conflict.
Over engineering is a major problem within the software industry. This problem has led to the adoption of ‘lean software development’ – at least amongst the agile folk. Lean software development is writing code to support the current set of requirements and nothing more. This is not as easy to do as one might think.
As developers we naturally tend to make assumptions as to what the user, or system, will need. In truth, it is very difficult to accurately predict the future requirements of a system. Coding to meet our assumptions will inevitably lead to over engineering.
We should not let our intuition guide us into false requirements. As strange as it may sound, it takes a concious effort to stop ourselves from doing extra work. We need to adopt a ‘lean coding culture’. We need to constantly remind our selves to stick to lean software development. In agile teams it is common to hear developers reminding each other with certain acronyms and expressions e.g. ‘do the simplest thing that works’.
‘Do the simplest thing that works’ is in-line with lean software development, although it can be misleading. Some people interpret this as ‘do the first thing that comes to mind’ e.g. slap on another if statement – that is a simplistic solution and not a simple solution. If you take a quick and dirty simplistic approach you will end up with a big ball of mud. You need to do the simplest thing that works. The thing that works is something that can be tested, it is something that does not add unnecessary complexity. Therefore the simplest thing that works is not necessarily the quickest and easiest thing to do.
