Nieuwjaarswens 2013!

Hallo!

Over de nieuwjaarswens 2013 moesten we even nadenken. Hoe breng je nu een wens om "er een knallend en vlammend 2013 van te maken" over?

Gelukkig hebben we hier voldoende brandbare middelen om aan deze wens vorm te geven :-)

En goed voorbeeld doet goed volgen, daarom hebben we de eerste 15 seconden van 2013 voor onze rekening genomen :-)

We denken dat het geslaagd is, maar oordeel zelf...

Of : http://www.youtube.com/watch?v=T7AoCw1uPII

Maak een opvallende presentatie.

Prima advies voor het maken van een opvallende presentatie.
Hier.

Waterdruppel.

Per ongeluk gemaakte foto tijdens het klussen aan een oldtimer.
Canon IXUS 100IS.

Waterval en Agile

Een interessante discussie over Waterval en Agile op LinkedIn.
Voor degenen die geen lid zijn van deze groep (The Project Manager Network - #1 Group for Project Managers) volgt hier de discussie:

Agile Vs Waterfall Model

What do you think is the key differentiator between Agile Vs waterfall model in project management and what should be the criteria to choose one of the model for a specific project?

Francisco Leo • IMHO biggest differentiator is the visibility the stakeholders get in the project and how things interrelate, this of course from a software project point of view.

Andrea Stewart • I agree with Francisco. The biggest difference is the participation of the stakeholders. I do think that the waterfall model still has its uses in a case that you are providing a product that the end consumer does not know that they need. Even in this case, you would still want some kind of end user feedback,

Sanjay Gupta, PMP • I agree with you. Not so clear requirement and customer continues involved is key factor which sought for Agile based implementation.
Waterfall model will not be able to effectively handle these changing requirement.

-Sanjay

Manoj Vadakkan • Hello!
Francisco and Andrea pointed out the customer collaboration aspects. Sanjay, you are pointing out the responding to change aspect. There are two other major factors and all four of them are documented here :-)

http://agilemanifesto.org/

That is a good start.

Frederick Ayala • Hi Sanjay,

The paper of Winston Royce is very interesting for the comparison that you are making. Also there is a lot of interesting papers at IEEE, PMI and articles in Scrum Alliance.

You can compare them in several ways such as: how the requirements specification, quality assurance, change management and maintenance processes are done. For instance, regarding to the requirements specification process:

Winston Royce expressed on his waterfall paper: “I believe in this concept, but the implementation described above is risky and invites failure”. The main reason of he said this is that excessive time and effort is dedicated for full detailed requirements specification on the very first stage but tested on one of the latest stages. [1]

On the other hand. User stories focus on customer value. They don’t just assume a looseness of specification; they actually encourage it in order to foster a higher level of collaboration between the stakeholders and the team. A user story is a metaphor for the work being done, not a full description of the work. The actual work being done is fleshed out via collaboration revolving around the user story as system development progresses. [2]

Kind regards,
Frederick Ayala

[1] Winston Royce, “Managing The Development Of Large Software Systems”, IEEE, 1970.
[2] William F. Nazzaro, “New to User Stories?”, Scrum Alliance, 2010.

Subbu Subramanian • I am not sure if we can have such an open ended system design & architecture at the beginning of the project to accommodate the frequent business/functional changes that Agile methodology is advocating. I am not sure where one draws a line between accepting functional changes Vs. design changes ( to accommodate the functional requirements)

In a true agile process, can we execute a project on a fixed budget?

Rohit Gupta • Good Observation Subbu, biggest problem with Agile is fixed price project runaway cost and scope creep.

I prefer to use Waterfall (Iterative mode) for requirement sign off, use Agile for development and QA. Any new request should be part of change control/scope change and should be treated differently.

Ivo Verus • @Subbu: In fixed budget projects you can still use agile process but you take the risk of going over budget and not having implemented all requirements by the deadline provided. The reason is obvious, as client changes the requirements during implementation frequently, you have to change the code and spend extra time/money.
I'd recommend to establish good relations with client and client to trust you. When that is achieved there is a space to offer time&material cooperation model and use agile methodologies. At the end both parties will be more satisfied compared to when using waterfall methodology and 'fight' for every change request.

Subbu Subramanian • Agreed Ivo, T&M is the best option. Even if one follows component based design, frequent requirement changes will affect my design , how can i protect my design to avoid rework.

Axel Vanhooren • Sanjay,

To check I understand your question correctly, the question is about the impact of Agile (a software development philosophy) and Waterfall (a type of software dev. methodology) on project management.

1) With waterfall projects:
The project manager has an overview over the whole plan of the project. Since the insight increases as the project progresses, the first rough estimations become more and more precise. Plans can be more detailed (rolling wave) but may also need to be adapted to the evolving situation. This is provides an overall structure and vision of the project process. Reporting and following the progress of the project is easier. It is also somewhat easier to manage the interactions and dependencies between projects. But we must be aware that without close involvement of business people, to them, the reported progress is rather abstract. It are only numbers in reports.

2) Agile
Agile (Scrum) works with iterations/sprint and a backlog of a few weeks to a couple of months. Only the current sprint is defined. Since Agile is open to changes in features, new demands and changes in priorities, it seems to me that the view one has on the project doesn't reach further than the current sprint.
Moreover, the product owner, (in Scrum) the scrum master and the self-managed team take a part of the project management tasks on their shoulders. Additionally, Agile is lightweight. So it reduces all the project administration. I wonder whether there is still a lot of work left for a project manager.
As I understand, the burn down chart, backlog and the story points allow to measure and communicate progress. Since there is a great involvment of business people and product owner, and with the short sprints and feedback short after the delivery at end of the sprints, I would expect that lesser "measuring" is demanded by the client/business people.

The question about criteria to choose for one or another type of approach is a tough one. Comparisons of Agile and Watefall presented by Agile proponents are not reliable. The present a completely distorted picture of Waterfall (and only presumed weaknesses, the worse this picture is the better) and presumed qualities of Agile. One need to understand the real strengths, weaknesses, limits, required contitions and risks of both. Then, of course, you need to understand your (future) project, the expectations in terms of control, reporting and formalism of the client, the capability of the resources to work in one or another way .. and finally there are the personal preferences. What is your team absolutely don't want to work in one or another way?

Hope this helps.

Axel.

Ivo Verus • @Subbu: You shouldn't insist to client that design has to be fixed. In reality actually rarely happens design to remain as it was created at beginning. The main reason for that is that client knows what he/she wants to achieve, but doesn't know exactly how to achieve it. That is why there would be new requirements and changes of existing requirements once client see part of application or/and start using it.
The point here is that you as project manager should work with client and make him/her understand that changes are expected but that those changes will have some impact on a project. The team will work to make the impact as low as possible and to answer on client's need as those needs are most probably the market needs and key factor of project success.

Daniel Cora, MBA • Triple Constraint / Requirement(s)

Anastasia Chumakova • As Axel has rightly said, here we compare philosophy (Agile) with methodology (Waterfall). I wouldn't oppose them. I would just make another combination: i strongly believe that Agile goes perfectly well with Management by Objectives (MBO).

True that when using Agile we risk to miss deadlines or go over the budget. When Agile is combined with MBO, we have all the chances to avoid this evil.

At the same time, speaking of start-up projects, I would also mention, that projects of this type will inevitably surpass the budget. In most project this or that deadline will be missed. I find it natural. Though, it's already off top.

Charles D Fain • Axel Vanhooren and Anastasia Chumakovo voiced very good points. Rolling Wave project management overcomes the changes that occur during projects that need some flexibility. Agile is meant for shorter projects (probably with a few team members) and is light weight. They both have their purpose. I am finding that many companies are not buying in to the Time and Material charges because they are becoming more tarnished and knowledgable about development work. I like both models and feel that at times a hybrid is needed. Every project is different and when you have many stakeholders without close and direct colaboration or a few stakeholders with close colaboration on a shorter project might be the difference in management models. Just thinking out loud:)

Jack (Jeb) McIntyre • I don't see either approach as mutually exclusive, nor do I see either as the ultimate. Each has advantages and disadvantages, so I find a hybrid approach in which I pick and chose elements of each depending upon the project constraints to be the most productive.

One of my guiding principals is the smaller the project (limited scope, short time duration) the greater the probability of success. However some projects (or perhaps more correctly some environments) simply don't lend themselves to a pure "agile" approach. In those cases I use a waterfall approach for initially defining requirements and generating a master plan for the project (project roadmap). However within that master plan I typically make provision for a series of agile initiatives.

Note I make EXTENSIVE use of ASSUMPTIONS! This is one of the most critical aspects of project planning, and also one of the most overlooked.

I develop a project risk profile that identifies (to some extent) the confidence interval to apply against the project constraints (time, scope, budget). So, for example, in the end, if my assumptions are correct, I'm 90% confident of my time and expense estimates, but only 70% confident of my scope estimates (typical agile focus on fixed time, variable scope).

In my experience "pure" agile gives me the highest probability of success, but simply isn't viable in every environment or for every project. In those cases I resort to impure agile :)

Axel Vanhooren • @ Frederick

Hello Frederick,

Actually, there are some important nuances to your writing. Since the Agile community very often refer to this document "to proof" how well Agile is, I will expand a little bit to what I also read from these other sources about Agile and Dr Royces document.

Dr Royce is an interesting paper, but it is most often wrongly understood by the Agile community.
First of all, Dr Royce's paper doesn't concern software development in general. His paper is about his experience on software development in the space industry. It's about the specific organisation he worked for.
Then, his paper is about LARGE software development projects. Logically, Agile should be more suitable for smaller projects since different principles and techniques used in Agile are not really suitable for larger projects.
I do not recall Dr Royce mentioned changing requirements as an issue in his paper. However I do recall he mentions issues related to his particular context, namely the fact that one department is in charge of elaborating a complex computation resulting in a few lines of codes. An error in this small piece of code can with a pure sequential process and in that organisation only be detected at the end of the project. This means that that department must then redo its work. He also mention an issue that is more linked to the seventies (or earlier). He also mention issues related to the availability of limited hardware capability (timing, data storage and data transfer). These issues should better be solved upfront. But in 1970 and before, the hardware wasn't as powerful as it is today.
These issues has thus nothing to do with the reasons the Agile community are talking about.
He starts with drawing a waterfall-like process consisting of the phases: system requirements, software requirements, analysis, program design, coding, testing and finally operations. What he says that this process is risky and invites failure. But he also states that he believes in the concept!! Then he goes on with improving this process to deal with the risks he mentioned.
It is interesting to note that Dr Royce in the waterfall already include jumps to earlier stages. This means that design or requirements are not for 100% frozen and can be adapted. He also advices to start with an overall architecture/design which can be based on the requirements gather by then even if they are incomplete requirements. Apparently, since 1970 the waterfall can thus work with incomplete and unstable requirements. This should be one more revelation for the Agile proponents ;-)

To avoid late testing, the IT community inventing concepts like prototyping, user stories, use cases, mock-up screens, proof of concept, the V and W-testing models, .. This means that the business community have tools to follow the whole software process and to discover what the software will look like as the project progresses. If they don't, then it is a human problem and not a problem linked to the waterfall.
Dr Royce says that the waterfall is a fundamentally sound process, but, to cope with the particular risks he mentioned he adds 5 improvements that should solve them.

Dr Royce paper is an interesting starting point, but we must take into account that it is written in 1970 and for a specific situation. Meanwhile, IT has evolved.

Best regards,

Axel.

Art Jones • The sweet spot draws on both Agile and Waterfall. Anastasia, Axel and Charles, I agree. I like good waterfall projects that build in flexibility and real life through modelling, change control, and rolling wave. Boring meetings can be amped up by engaging Agile/SCRUM methods too.
Too often, I see waterfall painted solely as a heartless machine with no suspension, bulldozing hills, filling voids, intolerant, and single minded as it rolls over people. Projects managed this way die or run people off.

Axel Vanhooren • The document the Agile community often refer to is named "Managing the Development of Large Software Systems" and written in 1970 by Dr Winston W. Royce.

By googling the title on the web you can easily find it (pdf-file).

John (Jack) Stewart • As indicated earlier, I like Agile/Scrum since the small sprints help reduce the inadequacy of requirements when you are "creating" something. Waterfall is better when the outcome is known (equipment installation, building a house) and more predictable

Frederick Ayala • Hello Axel, thanks for your comments.

I'm in agree with you, the paper is misunderstood. I wrote the "Common view" of Waterfall but indeed, Dr Winston W. Royce. wrote about iterations on the software lifecycle. We can see this in the "Figure 7. Step 3: Attempt to do the job twice - the first result provides an early simulation of the final product." of the paper.

Dear all, take a look at this video, it's called "The Rise And Fall Of Waterfall"
http://www.youtube.com/watch?v=X1c2--sP3o0

Anyways, companies should evaluate the unique characteristics of the project in order to decide if they are taking Waterfall, SCRUM or a mix of both.

Kind regards,
Frederick Ayala

John M. Mereness, Esq. • Design the system to match the needs of the project and the people involved. I see too much "we are going to do it X way" and all that does is flounder.

Thierry Labriet, PMP & IPMA-B • Hello!

How is it possible to associate stakeholder involvement with Agile approach? Does that mean that stakeholders are not or merely involved in waterfall approaches? No at all (I hope for all of us!!!).

For me the key distinction is the stakeholder expectation:

1) My project clients have a very good and non-negociable (we can dream!) idea of what they want --> I go with a waterfall approach: The scope is a given and the cost and time can be derived from the expected scope. That works fine with FP contracts.

2) My project clients have strong constraints on time and/or budget and would like to have the most valuable scope delivered within these given constraints --> I go with an agile/iterative approach. This fits very well with unclear requirements in the R&D or many IT projects for instance.

That is my personal experience.

In the given feedback, I record many interesting learnings though!

Many fruitful projects to all of you in 2013!

Thierry.

David Lahuerta Clemente, PMP • Hi all,

Just come from a training on PMI - ACP and I think there is a general mix (confusion) between project management and product development... and the use of lifecycles for them.

Key points for me on the discussion:

1.- Most of ideas behind Agile Manifesto are good ones and common sense, no one can deny, but...
2.- I agree Predictive and Adaptative PM are not mutually exclusive, Well managed waterfall can be as Agile as Scrum, and viceversa
3.- In Agile the less "sexy" subjects of Project Management are neglected (Communications, Risks, Financial aspects, etc) To me is synthom of poor Management
4.- I am not comfortable with the way Agile is presented "against" Predictive PM, it seems like there is no posibility to change at all in PMBoK... but what is change management for? Not all is written on stone ;-))

Finally, the point that makes me unsure about agile is the fact that, being so flexible with requirements, you might end up with something totally different to what is required.

This can be ok sometimes, but some others... if you want to build a plane, and you finish with a bridge, that's beyond project management... :)

Regards,

David

Paul Hulme • Use something like the DSDM questionnaire to help you decide (you can substitute "Agile" for DSDM Atern in that questionnaire if not using DSDM).
http://www.dsdm.org/wp-content/uploads/2010/11/template_project_approach_questionnaire.xls

Cheers,
Paul.

Robert W. Cooper • Both the Waterfall method and the Agile method of software development have their uses. Although Agile arose as a reaction to the limitations imposed by the Waterfall method, Waterfall still retains its relevance as a better method when the environment is stable with no room for changes, when frequent interactions with ends users and other stakeholders are not possible, or when there is a risk of key developers quitting the project midway.

Agile is a lightweight method. As software developers focus on smaller work areas, overhead becomes less, and the project costs considerably less than when using the Waterfall method. When customer requirements are hazy, or the business environment is uncertain, Agile methods that allow making frequent changes, and testing during the construction stage remains the best choice. Successful execution of Agile projects nevertheless requires highly skilled and competent developers, and stakeholders who know what they want. With the scope to accommodate changes, an Agile project can easily lose its way.
http://www.brighthubpm.com/agile/50473-agile-vs-waterfall-is-there-a-real-winner/

Manoj Vadakkan • Hello David L,
I appreciate your comments and it sounds like you had some great discussions in the ACP training session ( btw, I also conduct ACP trainings :-)

I also use to be an Adaptive Project Manager before even discovering Agile.

Yes, I agree, there is Change Management, there is process for that when we need to change. To me, Agile says, there is going to be change for sure. So lets put the process together such a way that we welcome change. Feature Driven Development is helping us to do just that - or call that progressive elaboration.

The "less sexy subjects": If you take the case of Scrum. Yes, they are not explicitly prescribed in Scrum. That is to keep it simple and keep it in such a way that organizations can do whatever that fit within their organization, projects, and need.

Liked your analogy of starting with a Plane and ending with a bridge: :-) I see it as a good thing assuming it is the customer who was in control when changing the plan. I woud argue that if we are doing frequent delivery and have more involvement with the customer as Agile asks us to do, we will figure this out earlier than later.

Cheers!

Manoj

Scott Albers • #1 Rohit mentioned Scope Creep as a weakness of Agile Scrum: It depends on the environment. I used Scrum to protect AGAINST scope creep with a small firm's CEO who is an R&D Neuro-Scientist: I defined sprints as "once in motion, nothing of the plan changes" within that sprint. Which allowed at least a couple weeks to let the "burning new idea" factor of a new change idea cool off and an opportunity to collect and discuss the pros and cons of adding the change on the next sprint. Imaginary boundary? Perhaps, but it was a key to that project's success.

#2 This discussion is "Agile vs. Waterfall" - however I have yet to meet anyone who is actively using pure Scrum. Everyone does a hybrid, form-follows-funciton approach. And why not? As long as what parts of what are clearly understood by all parties and it serves to optimize the outcome.

Has anyone come across a archetypal hybrid that could be used as a template?

Sanjay Gupta, PMP • @Frederick Ayala: You pointed out the key aspect of the Agile. Requirement begins with a metaphor in the form of user stories and then design and development gets completed for each sprint while rests of the stories are being evolved.

It gives customer enough flexibility to focus on key aspect immediately and working on less important one as time progress.

We can also compare it with Pareto analysis, which tells us that 80% of problems can be addressed if we focus on 20% of key issues and addressed them effectively. This principle can be used in Agile as well. If we focus on 20% key requirement at a time then we will be able to deliver maximum value to our customer.

-Sanjay

David Lahuerta Clemente, PMP • Manoj,

Thanks for your comments, this:

"lets put the process together such a way that we welcome change"

Is probably the most sensible explanation read so far. But then this:

[...] to keep it simple and keep it in such a way that organizations can do whatever that fit [...]

Takes me back to the idea that this is no mature project management... Kind of "as I do not like it, I forget about it" mindset. (I know, I am being a little provocative here...)

Scott:

You just highlighted one of the paradox I find in Agile... on one side, A. Manifesto says "we welcome changes" but then "once in motion, nothing of the plan changes"

So, not all changes all times (exactly as in traditional Project Management) To me, this is is perfect... but can be for an iteration in Scrum, or as well for one "fall" in waterfall... :) so then, what is really the diference?

Interesting post, thanks to all.

David

Sanjay Gupta, PMP • @Subbu: Your point is valid and Ivo has responded very well to your query. Regarding design change, Agile has one more principle of keeping the design simple and good collaboration among designer and developer. Once initial framework is designed then there is very less chance that any change in requirement will impact the design heavily. It may be a slight change.

But, whatever is the impact, it needs to be implemented because delivering value i.e. customer requirement is the key behind the Agile methodology instead of resisting change due to design change or impact on schedule etc.

Since customer is involved very closely with the project hence all these aspect needs to be discussed with customer and make decision, which provides maximum value to customer.

- Sanjay

madhusudhanreddy yannakandla • waterfall method stands for predictability, while Agile methodology spells adaptability. Agile methods are good at reducing overheads, such as, rationale, justification, documentation and meetings, keeping them as low as is possible. And, that is why Agile methods benefit small teams with constantly changing requirements, rather more than larger projects.

Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.

http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/

go through above link get more information about to methods

--Y.Madhusudhan Reddy

Manoj Vadakkan • Hello David,

"[...] to keep it simple and keep it in such a way that organizations can do whatever that fit [...] " ....Takes me back to the idea that this is no mature project management..

Let me explain: I didn't mean to say that - people get to do whatever they want to do. What I meant to say is that, when speaking of Scrum, Scrum itself doesn't specify every details of every pieces of the process. For example, it doesn't tell the team to test the software. But Scrum is used more often for Software development. What that means is that Scrum doesn't prescribe all the details of everything. It keep it to the bare minimum.
It leaves it up to the organization to fill that gap. And that needs to be filed.

Manoj Vadakkan • Interestingly, even after a decade of defining Agile, we still have this discussion. More often than not, it end up as a religious discussion of what is better? Have any one seen this before ? :-)

To me, it is not a question of what is better or what is the difference. Being Agile is not even a goal for me. Being better organization that delight the customer ( and hopefully make a ton of money too in the process!) is a better goal. To that end, I would ask the question: is that current way of working, doing business, organizing teams, delivering products working? If it is, don't changing anything. On the other hand, if it is not working, if we do need to make some changes, well, then identify those changes. What are those results you are after? Ideas under the Agile umbrella might give you some tools and techniques to help you get there.

Jeff Schreck • Isnt saying "Agile vs Waterall" like saying Chevrolet vs Samsung? Do the two really apply in comparison? Waterfall is a fairly ridged and well defined method. Requirement, Design, Implement, Verify, Maintain... or some variant of that. Where Agile is a concept, not really a method.

That being said, I don't think either ideal exists in purity, nor do I think it is possible to execute either ideal... the kludge we get someplace in the middle is typically more effective.

Axel Vanhooren • Maybe I would use Agile for small user-oriented software acting locally (eg personal information managers, small social media apps, ...), or when there is a need to enrich larger software systems with user-oriented features.

But I would definitely avoid it when it comes to more serious corporate IT systems or critical systems. Then a more systematic and structured approach is more appropriate.

Johan Johansson • I think it's important to consider budget relative to technical complexity (for software or websites). I've written detailed specifications that were simply not read or ignored by freelance developers because the project didn't have enough of a budget for them to care. A few years ago I adopted an agile method for lower budget projects with simpler requirements, and have seen marginal difference in quality and turnaround time relative to using the waterfall method.

Neel Gautam PMP, CSSGB, ITIL V3, MCTS, MCAD, MCP • First of all, great question and awesome discussion so far :). Obviously, these two are bound to cross boundaries and not mutually exclusive per say. However, let’s assume (for the sake of responding to the question) that they can be clearly separated and are mutually exclusive. Of course, it is so tempting to use those two words “it depends”; yet I’ll take a stab at it by sharing my 2 cents.

1) What do you think is the key differentiator between Agile Vs waterfall model in project management
-- Waterfall methodology to me is more targeted towards long term system/application stability whereas Agile philosophy seems more on setting things in motion, realizing faster Return On Investment.
-- Stakeholder buy-in and involvement.

2) What should be the criteria to choose one of the model for a specific project?
-- Choose Waterfall
* IMHO better for larger projects/releases or with a large team (I’d say over 15-20 resources).
* Better for really complex projects as requirements are clearly defined in one place. For large projects with complex requirements, agile seems to create confusion down the road (20 sprints later, no-one really knows the big picture as all requirements are broken into stories and use-cases).
* Generally better suited for start-up projects, big projects, global deployments, larger teams with multiple geographies.
* Better choice when you’ve room to build and develop the team and their skills.
* Clearly defined Gate (Entry/Exit) criteria.
-- Choose Agile
* Ideal for non-start up Project (incremental enhancement/operations releases).
* Ideal for smaller teams (up to 20 resources MAX).
* Better choice when team can work cohesively as efficient and effective unit (even better when team members have worked with each other for a bit).
* Works best when you have solid buy-ins from stakeholders and they are actively participating.
* Team needs to be highly skilled and there tend to be almost no time for learning curve in sprints.

It’s so dangerous to generalize particular methodology/philosophy to particular type of projects etc… but, having said all that; there; I’ve said what I wanted to on Agile v/s Waterfall! I’ll run for cover now!!!!

Art Jones • I associate rigidity and adaptability with the person, not these tools. A grumpy purist PM can turn any process or tool into some painful torture. "When all you have is a hammer, everything looks like a nail." PMP, SDLC and Waterfall describe a shop full of tools. Some projects require 1 or 2, and you are done. You seldom use all of them. I like this description of a colleague in Jacksonville, John Watson. Agile and SCRUM can easily become tools of torture as well. Been there, seen the pain too.

Unwittingly, I use Agile methods, I have conducted SCRUMs unknowingly to meet deadlines. Mind you it was not the SCRUM in a purist sense. AND some of my projects may not appear as SDLC by those purists as well.

Shahbaz Khan • In today's dynamic world, static management approach brings staleness to the practice of project development. While you cannot go about doing agile or prototype based development in a construction project, projects within the IT, business, process and research based programs are ideal. But the main issue is that at what point will there be the acceptability or completion be ascertained? There can be situation where endless changes may plague a project believing we are always on a path to agility. Somewhere along the line is a need for vetting of the fact that project has ended because primary goals and objectives of the projects have been met. Another issue within agile approach is the level of acceptance of disruption of normal operations when stakeholders are intimately involved in a project utilizing agile methodology. Depending on type of operations, not all stakeholders are a great fan of the approach.

Omar D'Angelo, P.Eng • I come from the Aerospace sector and depending on the size of the project, either or both could be used. For large projects with well defined SOW, I believe the waterfall approach is better, particularly when dealing with your client. The SOW is usually very well defined and key requirements should not be evolving with the product; implementing Agile (in my opinion) would introduce unwanted flexibility at this level. You could still implement an Agile methodology internally once requirements are sufficiently broken down and prioritized (per system, or other logical subdivision) to be managed as smaller, individual projects. Later in the project Agile would be appropriate for managing deficiencies where they can also be grouped and managed as small projects. For other projects in which requirements are constantly being added (hopefully new rather than changing), Agile is certainly an excellent approach.

 

MooijNijmegen.nl bed and breakfast.

Vriend Leo heeft een bed & breakfast geopend in Nijmegen. Op een bijzonder mooie locatie, namelijk tegenover de ingang van de Ooijpolder. Het is een fraai en comfortabel appartement voor vier personen.

Dit is de plek (klik op de kaart voor een vergroting):

Het ligt dus vlak bij het Hollandsch-Duitsch gemaal, precies daar waar de stuwwal begint (voor de Nijmegenaren: precies onder aan de trap tegenover Belvoir).
Het is er ook verrassend rustig, het geluid van de stad gaat er overheen, zo lijkt het.

Het is een uitstekende plaats om.
- de Ooijpolder in te gaan (je bent meteen bij de ingang).
- de stad in te gaan, onder de Waalbrug door ben je zo bij de benedenstad.
- te gaan wandelen op de stuwwal (begint op 1 meter afstand :-)
- te gaan hardlopen (zowel vlak als heuvelachtig).
- te overnachten bij de Nijmeegse evenementen zoals de Vierdaagse en concerten.
- en als je de weg af fietst-rijdt ben je in no-time in Duitsland.

MooiNijmegen is een compleet ingericht appartemen. Voor degenen die Leo niet kennen: dat doet ie errug goed (inclusief het nieuwste Philips koffiemaalapparaat :).
Met supersnel Internet, natuurlijk

Zelf vindt ik de prijs voor een overnachting laag, zeker als je het per persoon rekent.
Maar oordeel zelf: www.MooijNijmegen.nl

Het bed and breakfast is nu nog onontdekt. Wil je boeken, doe het dan nu: (bijna) alle evennementen-, vakantie- en concertdatums zijn nog vrij!

Stirlingmotor Conrad

Simpelweg zet een Stirlingmotor warmte om in kracht (beweging).

Wikipedia beschrijft hoe de motor werkt. De Nederlandse versie heel kort, de Engelse versie uitgebreid, met zeer fraaie animaties.

Conrad.nl verkoopt een bouwpakket van zo'n Stirlingmotor.
Het bestaat uit 150 kleine onderdelen en is in 2-3 uur in elkaar te zetten (behalve als je Tycho heet, dan klok je 1:05 :).

Het gebouwde model.

De warmtebron (een theelichtje) en de motor zelf.

En het werkt!

Het model kost €45.
Enerzijds is dat €45... Anderzijds bestaat het model uit 150 onderdelen en is het een unieke introductie in de Stirlingmotor.
Al met al: zeer de moeite waard!

Prijzige domeinnamen...

De lijst met domeinnamen die het meest geld hebben opgeleverd: hier.

Grootste gemene deler van deze domeinnamen:
- het zijn vrijwel allemaal .com domeinen.
- korte woorden zijn het meest voorkomend.
- enkelvoud of meervoud.
- populair zijn de gok-, sex- en reisindustrie.

Maar er zijn ook uitzonderingen.
Dus als je nog een leuke domeinnaam hebt liggen...

Gratis boekhoudprogramma Pap.

Pap is een een boekhoudprogramma dat voor "klein" gebruik (zoals een ZZP'er) gratis is. Je krijgt dan alleen hulp per e-mail.

Hier wordt tref je een soort review en opsomming van de mogelijkheden aan. Behoorlijk uitgebreid dus. Naar eigen zeggen zijn er bijna 20.000 gebruikers van Pap.
De site Boehoudreview geeft aan dat Pap vooral geschikt is voor ervaren boekhouders. Zie hier.

En hier kun je Pap ophalen.

Het lijkt er op dat de strategie van Pap is: kleine visjes gratis binnenhalen en als ze groot zijn laten betalen.

YouTube, wat scoort?

De afgelopen jaren heb ik flink m'n best gedaan om een aantal filmpjes te maken en die op YouTube te zetten. Eigenlijk omdat ik nieuwsgierig ben wat er nu wel interessant gevonden wordt en wat niet.
Er zitten doorwrochte werkjes bij (met mijn beperkte talenten dan ;-) en van die filmpjes die je maakt omdat je er toevallig langs loopt.

De meeste filmpjes halen de honderd kliks niet eens. En wat heeft er nu het best gescoord met 39.533 kliks en 54.234 minuten kijktijd (1,37 minuten per keer dus)?

Dit...
Niets doorwrochts, geen sjieke videocamera, maar met een fototoestel in een paar minuten gemaakt en onbewerkt op YouTube gezet.
Uit de hand geschoten in 2 minuut 10.
Wordt bekeken van Groenland tot Australië...

Marktplaatsen voor ZZP'ers.

Over marktplaatsen voor ZZP'ers: een overzicht.

Airbus A380 Emirates boven de Bijlmer

Kwaliteit van de foto is zeer matig maar het is 'm echt, de Airbus A380 van Emirates boven de Bijlmer. Relaxed vliegend op weg naar Schiphol. Komt dagelijks rond 13:00 - 13:15 uur, afhankelijk van de windrichting natuurlijk.
Hier op 6 november 2012, foto met iPhone 3GS.
Een klik op de foto maakt de foto groter.

Zon en wolken boven station Amsterdam Bijlmer Arena.

Zon en wolken boven station Amsterdam Bijlmer Arena.
iPhone 3GS, 28 november 2012. Een klik op de foto geeft een vergroting.

Duizeligmakend trappenhuis.

Best mooi zo'n trappenhuis...

IKEA dependance in Nijmegen ;-)

Tja, kom je je 's morgens vroeg op Nijmegen CS, staat daar een dependance van IKEA :-D
Wel handig, rechtstreeks vanuit je bed de trein in. Nog handiger zou een IKEA-slaaptrein zijn, maar ok., dit is een begin :-)

Neurale netwerken.

Een nieuwe generatie neurale netwerken. Link.

Bomen, sneeuw en zon bij de atletiekbaan.

Deze foto is door Ilona gemaakt achter de atletiekbaan in Nijmegen, tussen de Heemraadstaat en de Scheidingsweg dus.
8 december 2012, na een flinke sneeuwbui.
Camera: Canon Powershot A3300 IS

Gewoonte aan- of afleren.

Een gewoonte afleren of aanleren. Dat is niet simpel...
Deze App helpt. Heel simpel. En het zou wel eens heel effectief kunnen zijn...
Link hier.

Sinterklaas gedicht maken. Maar niet op papier.

Toegevoegd: O ja, gedichten maken gaat al een stuk gemakkelijker met Mick's Rijmwoordenboek (is gratis, klik linksboven op Rijm). Klik hier.
-----------------------------------

Je wilt een béétje origineel Sinterklaasgedicht.
Vergeet het maar. Die zijn allemaal al geschreven ;-)

Maar wat wel origineel is om een Sinterklaasgedicht op een eigen Internetpagina te zetten.
Kijk, dáár kun je mee aankomen!

Maar is dat niet moeilijk?
En kost dat niet veel tijd?

Nee.

Probeer het zelf maar eens. Vijf minuten om je Sinterklaasgedicht op Internet te zetten. En het ziet er nog goed uit ook.
En natuurlijk een dag om dat gedicht te schrijven ;-)

Waar? Hier.

Werkt zo:
1. klik "Create a new page".
2. klik op "Add Your Title Here". Dit is de hoofdregel. Kan zoiets zijn als "Voor Els, van Sint".
3. klik op "Add your Post here...". Hier kun je tekst en foto's kwijt.
4. klik "Publish".
5. haal bij "Page URL" de letters en cijfers aan het begin weg. Geef in plaats daarvan iets als "voor Els" (zelf te kiezen) en een wachtwoord (onthouden!).
6. klik weer "Publish".
7. er komt "Done! Now share your page". Kun je wegklikken (tenzij je dit op Twitter wilt zetten, kan ook).
8. op voorels.pen.io zie je het resultaat.

Je kunt die link naar iedereen sturen.
Dit is natuurlijk een eenvoudige, je kunt het zo mooi maken als je wilt.

Dode links opzoeken.

Dode links opzoeken in je website? Xenu doet het automatisch. Handig!

Informatie uit een foto.

Wat vertelt een foto over zichzelf? En over jou...
Kijk maar eens mee.

Allereerst: haal de fotoviewer Irfan op. Dat kan hier.

Geef bij het installeren "images only" op (en realiseer je dat vervolgens Irfan je standaard fotopakket wordt! Als je dat niet wilt: niet doen). Op zich niets mis mee want Irfan is erg handig als je snel even wat wilt veranderen in een foto (verkleinen, knippen, plakken, rode ogen weg).

Download daarna op de "Plugins" en voer die uit. Dat kan hier.

Open Irfan en haal je foto op.
Die ziet er bijvoorbeeld zo uit:

Tik nu in de foto op de letter "i". Je krijgt een informatiescherm.
Hier krijg je informatie: bijvoorbeeld de grootte, het moment waarop de foto is gemaakt, het aantal kleuren.





































Klik links onderin op EXIF info.
Je krijg meer informatie: het fototoestel, de belichtingstijd, ISO, enzovoort.

En helemaal onderin staat "Show in Google maps". Als je daar op klikt krijg je de exacte positie op de kaart. In dit geval 52.313500,4.947000: station Amsterdam Bijlmer Arena...

Oftewel: deze informatie vertelt je precies waarmee de maker de foto heeft gemaakt, wanneer dat was en waar hij of zij zich bevond...
 

 

Shop in Facebook.

Snel een shop in Facebook? Ik heb Mercadoo geprobeerd. Het heeft beperkingen, maar ik had wel in een kwartier een shop.
Link hier.

Kost niets als je niets verkoopt. Als je wel wat verkoop kost het 6% van de bruto verkoopprijs, met een minimum van €1.
Maar dat is dan wel inclusief iDEAL.

Minpunten: veel kun je niet aan de layout aanpassen, je kunt je waren niet in groepen indelen. En je moet cookies accepteren.

Al met al de moeite van het proberen waard, zeker als je starter bent.

vWorker.com overgenomen door Freelancer.com

Op 21 november 2012 is vWorker.com overgenomen door Freelancer.com.

Dat werd kenbaar gemaakt met deze e-mail.

Alle vWorker accounts zijn al overgezet naar Freelancer. Zonder aankondiging vooraf.
Freelancer.com is een betaalde dienst.
Ben benieuwd hoe dit verder gaat...

Parkeerplaats Sinterklaas

Het moet niet gekker worden :-) Leuk bedacht.
Met dank aan Bart S.

Primafoonwinkel Amsterdam Zuidoost, 20 november 2012.

7H 2012

Zevenheuvelenloop 18 november 2012.

In 2010 en 2011 hebben we met simpele videocamera's de Zevenheuvelenloop gefilmd.
Dit jaar hadden we de beschikking over een betere camera en hebben we in 1080p gefilmd. Mooi scherp dus.

We stonden ongeveer 800 meter van de start (bij Groesbeekseweg 350), aan de rechterkant, 100 meter voor het tankstation.
We hebben alles in één shot gefilmd, anderhalf uur lang (de video is 20 GB groot). Alle 26.440 lopers komen voorbij.

Als je aan de onderkant van de video op het YouTube-icoon klikt, dan kun je de video daar schermgroot op 1080p instellen.

Zo zag ons "videostation" er uit.

Sinterklaas in Franeker.

Twee foto's in Franeker, genomen vanuit het Eise Eisinga planetarium richting intocht van Sinterklaas.
18 november 2012, 14:53 uur.

Een klik op de foto's geeft een vergroting.

Scaled Agile Framework

Je hebt meerdere projecten en meerdere Scrumteams voor softwareontwikkeling.
Wat is nu de relatie met je programma's en je portfolio?
Interesse? Kijk hier dan eens naar het Scaled Agile Framework.

Zorgverzekeringen vergelijken.

De Consumentenbond heeft haar "Zorgvergelijker" actueel gemaakt voor 2012 en online gezet.
Op basis van vraag-antwoord wordt er naar de bestpassende zorgverzekering gezocht.
Hier te vinden.

Lasersnijden in kunststof.

Erg fraai, een duits bedrijf waar je een ontwerp naar toe stuurt dat vervolgens met een laser uit kunststof gesneden wordt.
En vervolgens door heel Europa verstuurd wordt.
Redelijke prijzen.

Zij leveren ook de software waarmee je kunt ontwerpen.

Link.

Klassieke muziek, om mee te beginnen.

Nog nooit naar klassieke muziek geluisterd, waar begin je dan mee?
Probeer dit eens. Wellicht ken je meer klassieke muziek dan je denkt... :-)

Mozarts 40e door Waldo de los Rios.

Of Ravels Bolero in het kort. In 1080p.

En Strauss' zijn Zarathustra sprak ook tot 01:46...
Aanbevelingen:
- luidsprekers zo groot mogelijk
- volume: zo maximum wat het trommelvlies en de buren aankunnen ;-)

Of we draaien het om want wat het ook leuk doet is popmuziek door een klassiek orkest.
Hier Philadelphia freedom van Elton John in het Royal Opera House in Londen.

(Flex)BV: winst uitkeren.

Prima artikel over winst uitkeren uit de BV nu de FlexBV er is. Let op de gewijzigde aansprakelijkheid van de bestuurder.


Hier te vinden.

Creatief genie

Interessant om te lezen en te herlezen en er bij stil te staan... Hier.

Liberation Route

Flink wat aandacht in de pers over de Liberation Route in relatie met Nijmegen.
Met name de Gelderlander schrijft er over.
Dit zijn een aantal artikelen:

13 oktober 2012 - diverse artikelen in de "papieren" krant:
- voorpagina: "Liberation Route komende jaren al verzekerd van 2-3 miljoen euro".
- pagina 9: "Miljoenen voor uitrol van Liberation Route".
- pagina 29: "Vliegwieleffect WOII-plannen, haast geboden.
- pagina 34: "Liberation route" in Commentaar


9 oktober 2012: "Liberation Route van enorm belang". Hier te lezen.

8 oktober 2012: "Museum WOII in Nijmegen stap dichterbij. Hier te lezen.

Dit is de website van de Liberation Route.

65 projectmanagement tools

Hier tref je een overzicht aan van 65 projectmanagement tools.

Alfabetisch:

1stManager

5PM

Aceproject

Action Method

ActiveCollab

Agilezan

Asana

Assembla

AtTask

Basecamp

Celoxis

Centraldesktop

Clarizen

Clientspot

ClockingIT

Comindwork

Copper

CreativeProOffice

Deskaway

Do

Egroupware

EPMLive

Feng

Glasscubes

GoPlan

Groupcamp

Huddle

HyperOffice

Intervals

Kpi.com

Liquidplanner

Nirvana

No Kahuna

Nozbe

OnStage

Ouractionlist.com

Paymo

PlanDone

Planzone

Podio

Producteev

Projectpartner

Projectplace

Projecturf

Projjex

ProofHub

ProWorkflow

Same-page.com

SantexQ

SevenOffice

Smertsheet

Teambox

TeamLab

Teamwork

TeamWorkLive

Thymer

Trello

Vertabase

VisionProject

Visma

WhoDoes

Wrike.com

Wunderkit

Yanomo

Zoho