Agile Lecture (Project Management)

Welcome to the discussion about this lecture. Here you can ask questions or post feedback about this specific lecture.

2 Likes

Hello Ivan,

I found the agile section very interesting but in my opinion you missed an opportunity here.
For me agile is not an unknown concept so when you talked about “blurred roles” it got my serious attention because I see this in my real life also as a problem. If communication comes from all directions to de developers (front end or backend) they get an information overload and we need a leader indeed.
But how will we put that leader inside that concept without ruining the concept itself and without ending in chaos.

Can you explain what your vision is to solve that problem ? Where would you put that leader en how would that affect communication ?

thnx, keep up the good work, I really love the videos

I little bit of feedback here. You started the video with the words that you’re gone talk about Agile…but you never explained what is Agile all about. Is it a concept, is it a software, is it a method?

It’s far more easier for the student if this basics to be explained in the very beginning rather then not at all.

1 Like

Hi. Maybe this is off topic but I’m gonna ask anyway. I have a question about leadership. Let’s say you are in a team and the leader in the team is not so good at being a leader. What is the best solution for it? Thanks for any answer.

1 Like

Hi. That does not sound like an Ideal situation too be in…

My experiance is to try to do my best for the business, but it depends on the leader, the business, and the hole situation around the problems you have with the leader. Why is he not a good leader? Is it only you who think this, If management thinks he does a good job, I have one advise. Start applying for work somewhere else, because it’s usually not worth the hassle to try to change the situation.

That’s what i think, but again, your answer is very general and hard to give a presise answer to you.

Good luck.
Ivo

1 Like

Hey you make a good point there. I guess it adds up more to the situation and everything around it. Thanks for your answer.

1 Like

@Timmy I have been in the same situation a few times. It was daunting at first for me, then I changed my approach. Remembering “The Peter Principle”, I began the approach of “this person will fail, so, how do I help them fail gracefully with less damage”. That may be a rather harsh way to approach the situation, but someone who is leading usually knows when they are failing. Step one was to keep my game on point. Step two is to help my immediate team members succeed if my game is good. Step three is to never badmouth anyone. That last one can be the toughest if you have gossipers on your team, so, avoid situations where others can gossip. I did that by keeping some distance from others. The results consistently were; my work was impeccable, the leader gave me good references, teammates remember me when positions open. I hope this helps you!

3 Likes

Thanks Michael for the response!
Its sounds really interesting and make me think of different situations. I never heard of the Peter Principle so thanks for that I will take a closer look into that principle.

2 Likes

Definitely do! I encourage people every chance I can who are in any supervisory, managerial, or executive position. The short version of it is; we get promoted for two reasons- success or longevity- however, we are promoted until we reach a position that we cannot do. I would go deeper, but, I’d like for you to take a long look at it.

3 Likes

This is a very interesting lesson. IMHO when we adopt these hints there are a couple of issues that should be fixed. As said an agile communication can take to blurred roles. Working properly in a team is good but as said some kind of leader is needed. So the issue is how to have an agile communication without breaking the roles and the leadership?

The second issue is in the use of MVP. Obviously customer is the king, but very often customers (even the open-minded to technology) are very conservative. So we have to fight against ourselves since we would believe in a completely different project, but money coming from conservative customer dictate a completely different line.

2 Likes

Hi @ivan In my opion you are too negative about other ways of running projects than Agile (for example waterfall projects). Agile is for sure not the silver bullet for Every project (lots of articles about this and also my personal experience). I am running many SAP programs >3 million euro for large multinational company’s they are coming back on Agile and product teams. You can’t have all required skills in your team when you are doing programs in a large organization. Agile teams are really focused on their own backlog and not how it interacts with other (Agile teams)

My conclusion first think carefully what fits best in every project to use as implementation methodology (or do certain parts Agile and others whaterfall). Agile fits most of the times best in development projects.

1 Like

This is a very useful video on AGILE and how the structure works when building a project.

1 Like

Thank you, this has largely explained to me why nothing works properly and the whole world has become one enormous frustration engine where the customer has become an employee who pays the company to do work for it, and there is definitely no concept of SERVICE or SERVICE ATTITUDE any more. Future shock has already happened, and the weak are being pushed to the margins and right off the edge. Hierarchy works for me. Actually, I think we need to learn how to do things more slowly and considerately, thinking about the effects of our products in the wider sense. Even the simplest things that were easy for people who know how to do things with physical tools in the real world have had unnecessary layers of complexity added to them. Question: have any of you lot ever kept a fire alight for a whole winter? That is my rant for today. The real world and nature are also VERY interesting.

1 Like

I’ve been working as an Agile coach in the past 5-6 years, helping organisations to be more nimble and deliver value early and continuously to their customers.
While a lot of people are getting stuck with basic practices, I like how @ivan focuses on customers (even developers, which is rare unfortunately), delivering value as early as possible, collecting feedback and adapt to change. Well done :slight_smile:.

Thank you for opening this topic. I’ve had experience with Agile now for over 10 years and personally I think it has become a dung hole for organizations. It has created so many unnecessary job roles in the form of a ‘scrum master’ who is supposed to keep up with progress of sprints. Now, there are terminologies like Epics, Stories, Sprints and whole slew of made up names that are confusing to people who’ve never worked with Agile before. My opinion on agile is that it is a revenge adapted by ignorant management as a revenge for years of having to listen to technobabble by engineers. For example:

I was given an assignment to integrate IBM’s discovery for Mainframe known as TADz. Tivoli Automated Discovery. The project began as Ivan describes it. We talked to the MF team to see what they would be comfortable using. I started to code the data integration that connected Pentaho to DB2 with a JDBC driver and got the POC done within about a week. Then I created a data model in the CMDB that could be used for Asset, Incident and Change management. The prototype was done in about 3 weeks. At that point I kept communicating with the director of the MF team to show what the end result will look like. During this time I joined roughly 3 scrum meetings each week. No-one in that meeting understood what I was actually talking about in technical terms. In my opinion it was a waste of my time to even attend. However, for each “Sprint” I have documented what I did as the weeks progressed. Eventually my solution got put into production and its life cycle as a product began for the company. It became very popular and easy to use because I’ve really thought it through and having Agile tracking on hand allowed me to predict short falls.

Next came updates. Details on what needed an update is not important, but what is important is that I was able to go back to Agile and track my notes on how I did the integration. I was also able to document my bottlenecks and demonstrate what eventually would become a maintenance component. Something I was putting weight on during the sprints that was declared as low in priority at the time, but became much more important as the product was used in production. I was able to “bring” the management team back to the date when I had made that projection and was told it was not important. I gained credibility at that point by having that vision. Although I have to say that for me, the coder, it was not hard to make that prediction. It was obvious, as Ivan points out, that “time” and competition are the enemies of quality. Agile can produce results “IF” used properly by management, but so far I’ve not seen good evidence that the scrum masters know the difference between a hole in the ground and their behind (where the Sun don’t shine as they say in Texas).

Thx for reading.

1 Like

Hi all,

Just wanted to chip in a few extra thoughts when it comes to project management.

Although I do generally agree with what is detailed in the lecture, there will be some other factors that feed into the how the project is managed., which I believe are important…Ultimately the trade off between Budget, Time and Scope.

Most projects will have these 3 constraints:

  • Though difficult I believe it is important to get as complete a set of requirements from the customer as possible, though I understand this can be difficult and potentially not feasible as ideas will also materialise as the project progresses, however have a clear set of requirements will also allow you to pull together an accurate costings for the project and time frame.

  • Following on from this, agree that consistent “workshops” with the customer are important, to verify that the development is heading in the right direction, however these also have to be managed and scope creep minimised.

As new functionality/requirements may impact the cost or time elements of the project.

Some functionality can be categorised as “must have” and “nice to have”, and then a potentially put into a phase 2 project.

  • Also, the importance of a defined set of requirements may arise at the end of a project, whereby you may need to show that a project has been delivered by ticking off the functionality checklist.

…bit of a brain dump, hopefully makes sense and is useful.

1 Like